signature author's guide

Final

Signature Author's Guide

IBM Security OpenSignature

IBM X-Force

06 July 2016 – Revision 36.070

Copyright © 2005, 2016, IBM Corporation.

Signature Author's Guide 06 July 2016 IBM Security OpenSignature

Table of Contents

1.Overview................................................................................................................81.1.Requirements.............................................................................................................................8

1.2.Vocabulary.................................................................................................................................9

2.Important Considerations..................................................................................102.1.Issue Numbers..........................................................................................................................10

2.2.Feature Limitations..................................................................................................................11

2.3.Customer Support....................................................................................................................11

2.4.Error Reporting........................................................................................................................11

3.Configuration......................................................................................................123.1.Variables...................................................................................................................................12

3.2.Rules........................................................................................................................................14

3.2.1.Mandatory Rule Columns ............................................................................................... 14

3.2.2.IP Addressing .................................................................................................................. 15

3.2.3.Port Numbers .................................................................................................................. 15

3.2.4.Action .............................................................................................................................. 16

3.2.5.Protocol .......................................................................................................................... 16

3.2.6.Source Address ................................................................................................................ 16

3.2.7.Source Port ..................................................................................................................... 16

3.2.8.Direction ......................................................................................................................... 16

3.2.9.Destination Address ........................................................................................................ 17

3.2.10.Destination Port ........................................................................................................... 17

3.3.Rule Options............................................................................................................................17

Final 2


3.3.1.Syntax ............................................................................................................................. 17

3.3.2.Option Classes ................................................................................................................ 17

3.4.Modifier Options......................................................................................................................18

3.5.Flow Tracking..........................................................................................................................18

3.6.Combining Matching Options..................................................................................................18

3.7.Deprecated Option Aliases.......................................................................................................19

4.Configuration Reference....................................................................................214.1.Statement Grammar.................................................................................................................21

4.2.Rule Option Grammar..............................................................................................................24

Final 3


4.2.1.ack ................................................................................................................................... 25

4.2.2.asn1 ................................................................................................................................. 25

4.2.3.byte_jump ....................................................................................................................... 25

4.2.4.byte_test .......................................................................................................................... 26

4.2.5.classtype ......................................................................................................................... 27

4.2.6.content ............................................................................................................................ 27

4.2.7.depth ............................................................................................................................... 29

4.2.8.distance ........................................................................................................................... 29

4.2.9.dsize ................................................................................................................................ 30

4.2.10.file_data ........................................................................................................................ 30

4.2.11.flags ............................................................................................................................... 31

4.2.12.flow ............................................................................................................................... 32

4.2.13.flowbits ......................................................................................................................... 33

4.2.14.fragbits .......................................................................................................................... 34

4.2.15.fragoffset ....................................................................................................................... 35

4.2.16.gid ................................................................................................................................. 36

4.2.17.http_client_body ........................................................................................................... 36

4.2.18.http_cookie ................................................................................................................... 37

4.2.19.http_header ................................................................................................................... 37

4.2.20.http_hostname ............................................................................................................... 37

4.2.21.http_method .................................................................................................................. 38

4.2.22.http_raw_uri ................................................................................................................. 38

Final 4


4.2.23.http_stat_code ............................................................................................................... 38

4.2.24.http_stat_msg ................................................................................................................ 39

4.2.25.http_uri ......................................................................................................................... 39

4.2.26.http_user_agent ............................................................................................................ 39

4.2.27.icmp_id ......................................................................................................................... 40

4.2.28.icmp_seq ....................................................................................................................... 40

4.2.29.icode ............................................................................................................................. 41

4.2.30.id ................................................................................................................................... 41

4.2.31.ip_proto ........................................................................................................................ 42

4.2.32.ipopts ............................................................................................................................ 43

4.2.33.isdataat ......................................................................................................................... 44

4.2.34.itype .............................................................................................................................. 44

4.2.35.metadata ....................................................................................................................... 45

4.2.36.msg ................................................................................................................................ 46

4.2.37.nocase ........................................................................................................................... 46

4.2.38.offset ............................................................................................................................. 47

4.2.39.pam_context .................................................................................................................. 474.2.39.1.content_javascript......................................................................................474.2.39.2.content_pdf................................................................................................474.2.39.3.dns_aaaa_query.........................................................................................484.2.39.4.dns_any_query...........................................................................................484.2.39.5.dns_cname_query......................................................................................484.2.39.6.dns_hinfo_query.........................................................................................484.2.39.7.dns_mx_query............................................................................................484.2.39.8.dns_naptr_query........................................................................................484.2.39.9.dns_ns_query.............................................................................................484.2.39.10.dns_ptr_query..........................................................................................484.2.39.11.dns_query................................................................................................484.2.39.12.dns_soa_query.........................................................................................484.2.39.13.dns_srv_query..........................................................................................48

Final 5


4.2.39.14.dns_txt_query...........................................................................................484.2.39.15.email_receiver..........................................................................................484.2.39.16.email_sender............................................................................................494.2.39.17.email_subject...........................................................................................494.2.39.18.file_content..............................................................................................494.2.39.19.file_name.................................................................................................494.2.39.20.http_form_data_raw.................................................................................494.2.39.21.mms_mm1...............................................................................................494.2.39.22.news_group..............................................................................................494.2.39.23.password..................................................................................................494.2.39.24.rpc_request..............................................................................................494.2.39.25.rtmp_stream_name..................................................................................494.2.39.26.smtp_command........................................................................................494.2.39.27.snmp_community.....................................................................................504.2.39.28.tls_server_name.......................................................................................504.2.39.29.url_data....................................................................................................504.2.39.30.url_post_data............................................................................................504.2.39.31.url_raw_data.............................................................................................504.2.39.32.url_raw_post_data....................................................................................504.2.39.33.url_user_agent_data.................................................................................504.2.39.34.user_login_name......................................................................................504.2.39.35.user_probe_name.....................................................................................504.2.39.36.voip_call...................................................................................................504.2.39.37.x509_in_file..............................................................................................514.2.39.38.x509_in_session.......................................................................................52

Final 6


4.2.40.pcre ............................................................................................................................... 53

4.2.41.pkt_data ........................................................................................................................ 54

4.2.42.priority .......................................................................................................................... 54

4.2.43.rawbytes ........................................................................................................................ 55

4.2.44.reference ....................................................................................................................... 55

4.2.45.rev ................................................................................................................................. 56

4.2.46.sameip ........................................................................................................................... 56

4.2.47.seq ................................................................................................................................. 56

4.2.48.sid ................................................................................................................................. 57

4.2.49.ssl_state ........................................................................................................................ 57

4.2.50.ssl_version .................................................................................................................... 58

4.2.51.tag ................................................................................................................................. 59

4.2.52.threshold ....................................................................................................................... 60

4.2.53.tos ................................................................................................................................. 61

4.2.54.ttl ................................................................................................................................... 62

4.2.55.uricontent ...................................................................................................................... 63

4.2.56.urilen ............................................................................................................................. 63

4.2.57.window .......................................................................................................................... 64

4.2.58.within ............................................................................................................................ 64

5.Examples with Explanations..............................................................................65

6.External References............................................................................................66

7.Revision History..................................................................................................67

Final 7


1. Overview

The OpenSignature feature provides a flexible language allowing customers to write specialized pattern-matching rules for their IBM Security intrusion detection and intrusion prevention system (IDS/IPS) products. These specialized rules can allow the products to detect network traffic specific to the customer's environment, and threats not detected with the products' built-in signatures. For example, OpenSignature rules can enable the customer to

monitor Layer 6 and 7 applications specific to the customer's environment report signatures that name a specific attack variant for customized reporting,

instead of relying on the IBM Security generic names

1.1. Requirements

IBM Security delivers the OpenSignature feature as a capability within the Protocol Analysis Module (PAM). The OpenSignature feature requires an IBM Security intrusion prevention product (sensor) to operate.

This document describes that syntax and capabilities of OpenSignature, it does not describe how the feature is presented or managed by a sensor product. Please consult sensor product documentation for information on OpenSignature activation and operation.

Final 8


1.2. Vocabulary

Attribute-Value Pair

(AVP)

An extension mechanism for PAM-generated events. Each event can contain a collection of string pairs, the attributes and their values, collectively referred to as Attribute-Value Pairs.

CIDR Classless Inter-Domain Routing. (see Chapter 6, External References)

EBNF Extended Backus-Naur Form. A meta syntax for representing context-free grammars, such as programming and other formal languages. Used to describe the syntax of OpenSignature rules. (see Chapter 6, External References)

Endpoint A communication termination address within a network, or a collection of them. For example, an IP Version 4 (IPv4) address plus port number.

GeneralOption

These options to OpenSignature rules allow OpenSignature, PAM, and the system operators to identify the rules when they trigger.

Issue ID PAM uniquely identifies detection signatures using numeric (integer) Issue ID values. Every event emitted by PAM and OpenSignature contains an Issue ID.

MatchingOption

An option to an OpenSignature rule that specifies matching of data in therule to data in the network traffic. If a packet data satisfies the matches specified by these options, the rule will trigger for that packet.

ModifierOption

These options to OpenSignature rules alter the behavior of the most recent preceding matching option in the rule. For example, following a content option and its argument by the nocase option causes that match to be case insensitive.

Signature An alternate name for an OpenSignature rule. This document considers the terms interchangeable.

SID Signature ID. An integer assigned by the rule author to uniquely identify a rule in detection reporting events. The Signature ID also controls the Issue ID reported when the rule triggers (see the description below of thesid general option).

Table 1.1: Specialized terminology in this document.

Final 9


2. Important Considerations

The OpenSignature feature provides a flexible language to create rules to identify various types of network traffic. It operates within the context of the deep packet inspection technology of PAM. That same flexibility that makes OpenSignature widely applicable allows authors to produce rules with unexpected consequences.

IBM Security cannot guarantee agent performance when using OpenSignature rules.

Authors must take great care when creating rules. Weak, incorrect, or overly broad or narrow rules can significantly impair the IBM Security agent in which the rules are installed. They can also disturb traffic on the monitored network(s). “Bad” rules can, for example,

cause the OpenSignature engine to run in a loop, “hanging” the agent block all network traffic to a segment, network interface, etc. severely reduce agent throughput cause agent performance problems not obviously attributable to the rule(s) require re-installation of the agent

Authors of OpenSignature rules should test their individual rules and rule sets carefully before deploying them in a production environment. Those tests should cover both the correctness of the rules and agent performance with the rules installed while the network supplies typical traffic to the agent.

2.1. Issue Numbers

OpenSignature detections generate issue numbers in the 6000000-6999999 range. Assignment of an issue number to a rule uses the following algorithm:

If the sid keyword is present, an issue id is calculated as 6000000 + (sid modulo 800000), resulting in an issue range of 6000000-6799999. If the resulting issue number is unique it becomes the assigned issue number.

If the msg keyword is present and the sid based assignment was unsuccessful, the msg value is hashed to seed an issue number in the range 6800000-6934463. If the resulting issue number is unique it becomes the assigned issue number.

The fallback case assigns an issue in the range 6934464-6999999 based on the relative rule number in the rule set. This is guaranteed to be unique, but may change if rules are inserted or removed ahead of this rule.

Final 10


The assigned issue number provide the linkage necessary to associate sensor responses with detections by a rule. That process exceeds the scope of this document. Please see the other documents in Chapter 6. External References (page66) for more information.

2.2. Feature Limitations

Though largely compatible with the Snort® tool's syntax, OpenSignature supports only a subset of that syntax. This document identifies all syntax and semantics that OpenSignature supports. It does not support anything not specified in this document.OpenSignature ignores Snort syntax elements that it does not support but reports them in the AVPs for the events produced by the rule.

OpenSignature does not currently support Internet Control Message Protocol Version 6 (ICMPv6). The icmp protocol in OpenSignature rules refers to Internet Control Message Protocol Version 4 (ICMPv4).

OpenSignature does not natively support IEEE 802.1Q VLAN tagging. All traffic is processed in streaming mode to minimize latency and resource

consumption. Rules utilizing the pcre matching option are subject to false negatives when the matched pattern spans TCP segment boundaries.

2.3. Customer Support

If you would like to report an error in, or request an enhancement to, this document then please contact your IBM Security Customer Support representative.

Note that IBM Security Customer Support cannot assist customers in writing or troubleshooting OpenSignature rules for customer environments. Customers requiring such assistance should contact IBM Security Professional Services.

Poorly written OpenSignature rules can cause agent performance problems. These problems may not be obviously related to the OpenSignature rule set. Therefore, IBM Security Customer Support may ask customers to disable the OpenSignature feature when reporting a performance issue.

2.4. Error Reporting

The Protocol Analysis Module (PAM) has no direct access to operating system resources, it relies on interfaces supplied by the hosting sensor product. When OpenSignature detects an error in the rules provided, it announces the error both in PAM log (that the agent maintains on PAM's behalf) and with a PAM event. These error events use Issue ID 5,900,001. The text included in the event describes the error.

Final 11


3. Configuration

OpenSignature configuration statements follow a syntax largely compatible with that used by the Snort open source network Intrusion Detection System from Sourcefire. Though it supports only a subset of the Snort syntax, OpenSignature can use a largenumber of Snort rule sets directly. OpenSignature ignores Snort syntax features that it does not support.

The OpenSignature rule parser fully processes each input line before considering any following input. Each rule must begin and end on the same line of input. Rule authors may include comments in the rules definitions using the '#' character. The parser treats the '#' character and all text following it on a line of input as a single space. The parser ignores all blank lines, including those that become blank when the parser discards commentary.

3.1. Variables

OpenSignature provides variables to ease customizing the rules to an environment and developing groups of related rules. Variables associate a name with a text string. Subsequent rules and variable definitions can reference variable strings using their name preceded by a “$” (dollar) character.

Final 12


Example

# Define variables customizing the rules to our network topology.

var HOME_NET 192.168.1.0/24 # Any host on 192.168.1.0/24 network

# Define variables for our port numbers to make the rules more readable.

var HTTP_PORTS 80, 8080

var HTTPS_PORTS 443

var WEB_PORTS $HTTP_PORTS, $HTTPS_PORTS

# Rules using the variables we just defined.

alert ip any any -> $HOME_NET $WEB_PORTS (sid:1; msg:”HTTP(s) Inbound Seen”;)

alert ip $HOME_NET any -> any $HTTPS_PORTS (sid:2; msg:”HTTPS Outbound Seen”;)

The example first defines the HOME_NET, HTTP_PORTS and HTTPS_PORTS variables. It then uses the HTTP_PORTS and HTTPS_PORTS variables to define the WEB_PORTS variable. Finally, it defines a rule using the HOME_NET and WEB_PORTS variables, and another using the HOME_NET and HTTPS_PORTS variables.

As shown above, a set of OpenSignature rules must submit a valid var statement defining a variable before using the variable in rules definitions, or in definitions of other variables. Most rules sets define all appropriate variables first, then define rules using them.

The association of a variable name with a value continues until PAM restarts or a subsequent var statement redefines it. The signature author cannot delete a variabledefinition, but can redefine the value associated with the variable. Note that, changing the definition of a variable will not retroactively change the contents of rules earlier in the rules set that have already used the variable.

OpenSignature has predefined some commonly used variables. These generic definitions work for many environments. However, most networks could tighten thesedefinitions considerably. Rules authors should ensure that their rule sets update these variables as necessary for their network environment. The following table lists the default variable definitions:

Identifier Default Value

HOME_NET any

EXTERNAL_NET any

DNS_SERVERS $HOME_NET

SMTP_SERVERS $HOME_NET

HTTP_SERVERS $HOME_NET

SQL_SERVERS $HOME_NET

TELNET_SERVERS $HOME_NET

Final 13


Identifier Default Value

SNMP_SERVERS $HOME_NET

SSH_PORTS 22

HTTP_PORTS 80

SHELLCODE_PORTS ! 80

ORACLE_PORTS 1521

Table 3.1: OpenSignature parser default variable definitions.

3.2. Rules

All rules begin with a mandatory seven column header. Each column is delimited by whitespace characters.

Outside quoted option argument strings, OpenSignature:• Ignores letter case• Collapses adjacent whitespace

Within quoted option argument strings, OpenSignature:• Respects letter case• Maintains whitespace

Rule options ordering is important for matching and modifier options. Modifier options always follow the matching option they alter. General options, on the other hand, can appear anywhere in the list of rule options.

Every rule may contain an sid (Signature ID) option. The sid for each rule shouldbe unique, so that operators can determine which rules produced which events.

Every rule may contain a msg (Message) option. The message should give the operator some idea of the situation to prepare them to resolve it.

Limits in a single rule:• Maximum number of characters depends on the host sensor implementation.• Maximum of 32 matches using the content, uricontent, and pcre options

(total of all three, not 32 each)• Maximum of 16 flag matches• Maximum of 8 IP(v4) options matches

Limits on Flow Tracking• Maximum of 256 flowbits per flow

3.2.1. Mandatory Rule Columns

Column Usage

1 Action

2 Protocol

3 Source Address

Final 14


Column Usage

4 Source Port

5 Direction

6 Destination Address

7 Destination Port

3.2.2. IP Addressing

IP addressing consists of a single IPv4 or IPv6 address, an address block using CIDR notation, an address range delimited by “-” (hyphen) or an address list delimited by “,” (comma) and enclosed by “[]” (square brackets). Address lists may contain addresses, ranges, blocks and lists. Any address element can be negated with a leading exclamation point. The string any is used when no IP address constraint is required.

Example

# Constrain rule to any destination except a single IPv6 address and portalert udp any any -> !1234::5678 80

# Constrain rule to a single source IPv4 address blockalert udp 192.168/16 any -> any any

# Constrain rule to a single destination IPv6 address block.alert udp any any -> 1234:5678:9abc/48 any

# Constrain rule to a list of source IPv4 addresses.alert udp [127.0.0.1,172.16/16,192.168.192.1-192.168.192.5] -> any any

3.2.3. Port Numbers

Port numbers are expressed as an unsigned 16 bit integer, a range of port numbers delimited by “:” (colon), or a list consisting of port numbers and/or port number ranges delimited by “,” (comma) and enclosed by “[]” (square brackets). Any port number element can be negated with a leading exclamation point. The string any is used when no port number constraint is required.

Final 15


Example

# Constrain rule to a single destination port.alert tcp any any -> any 80

# Constrain rule to a range of source port numbers.alert tcp any 6000:6010 -> any any

# Constrain rule to a list of destination ports and port ranges.alert tcp any any -> any [80,443,8000:8800]

3.2.4. Action

Each OpenSignature detection results in an event report to the underlying IBM Security sensor product. The action specified on the rule is effectively a hint to the underlying sensor product on what should occur based on the event report.

Sensor products may not implement expected semantics for all action types. When aproduct doesn't understand a particular action, it will treat the event as a standard alert. Please consult product documentation for your sensor to determine which actions are recognized.

3.2.5. Protocol

OpenSignature rules can inspect the network traffic of a number of protocols. The engine first compares the rule protocol to the protocol expressed in the packet. If thetwo match, the engine then checks the endpoints and direction specified in the rule. If these also match, the engine applies the rule's matching options to the packet. Should the rule match the packet's contents, the engine produces a PAM event describing the match.

3.2.6. Source Address

See 3.2.2

3.2.7. Source Port

See 3.2.3

3.2.8. Direction

This token identifies the direction of the network traffic to which the OpenSignature engine should apply the rule. The OpenSignature engine will apply the rule only to traffic moving in the direction indicated by this token.

Each token comprises two characters, with no space between them. OpenSignature recognizes two direction specifications:

Final 16


Token Meaning

-> Inspect traffic moving from the left (source) endpoint to the right (destination) endpoint.

<> Inspect traffic moving between the left endpoint and the right endpoint. Source and destination are interchangeable.

Table 3.2: The traffic direction specifications that OpenSignature recognizes.

3.2.9. Destination Address

See 3.2.2

3.2.10. Destination Port

See 3.2.3

3.3. Rule Options

In an OpenSignature rule, the protocol, source direction and destination columns select which packets the engine will subject to the rule. The rule options, on the other hand, identify packet contents of interest to the rule, as well as uniquely identifying the rule within the rule set.

3.3.1. Syntax

When rule options are present they must be enclosed within “()” (parentheses). Eachoption must be terminated by “;” (semicolon). Options that accept arguments separate the option name from the arguments using “:” (colon).

Example

alert tcp any any -> any any (msg:”...”; sid:1; content:”foo”; nocase;)

3.3.2. Option Classes

Rule options come in four groups: general options, payload matching options, protocol matching options, and modifier options.

General options allow OpenSignature properly to construct PAM events to notify the operator of the traffic detected. They also allow rule authors to annotate thoseevents with relevant information, like the rule revision or a global category for the match.

Payload Matching options specify payload data patterns required to satisfy the rule. These options apply only to TCP and UDP rules.

Final 17


Protocol Matching options specify data matches of the values in the various protocol header fields.

Modifier options alter the behavior of the most recent preceding matching option in the rule. For example, the nocase option makes content comparisons insensitive to letter case (in terms of the US ASCII character set). Some modifier options can alter the behavior of any matching option, while others apply only to certain matching options. The option descriptions indicate which modifier options apply to which matching options.

Authors can include multiple options of each type in the definition of a rule. By doing so, rules can define very complex matches. See section 3.6 Combining Matching Options (page 18) for further discussion.

OpenSignature supports only a subset of Snort's rule options. This document describes the options supported by OpenSignature. When generating PAM events to represent signature “triggers”, OpenSignature will include the unrecognized or unsupported options in the Attribute-Value Pairs (AVPs) of the event.

3.4. Modifier Options

The Modifier Options alter the behavior of Matching Options. Each modifier option alters the behavior of the most recent preceding matching option specified in the rule. In other words, the syntax is roughly

(match1 modifier1a modifier1b modifier1c modifier2 modifier2a ...)

Thus, each modifier option must be preceded by a matching option. Rules that supply conflicting modifier options for a particular matching option will find that OpenSignature respects the rightmost (last) of the conflicting modifiers and discards the rest.

3.5. Flow Tracking

Within OpenSignature, flow tracking applies to TCP streams after PAM and the OpenSignature engine have reassembled the TCP stream. The “Flow Tracking” feature allows authors to restrict their rules to specific TCP streams in the network traffic.

3.6. Combining Matching Options

Rules may combine matching options to implement complex matches. This can prove particularly useful for log rules, which must narrowly constrain the number of packets written to storage to preserve performance. The OpenSignature matching

Final 18


engine pursues matches from left to right within a rule. For example, assume a rule with the following options:

(content:”A”; content:”B”; sid:1000;)

When a packet matches the addressing required by the rule, the OpenSignature begins the attempt to match the payload of the packet to the rule. With these options, it will check to see if the first payload octet is “A”. If not, the engine rejects the rule for this packet. If so, the engine then checks to see if the second octet of thepacket payload is “B”. If so, it produces a PAM event with Issue ID 6,001,000. If not, the engine rejects that rule for the packet.

Adding a nocase option between the two content options would enable the rule to match packets containing either 'A' or 'a' as the first payload octet. Adding a nocase option after the second content option would enable the rule to match packets containing either 'B' or 'b' as the second payload octet. Adding both nocase options enables the rule to match packets containing either 'A' or 'a' as the first payload character octet and 'B' or 'b' as the second, i.e., “AB”, “Ab”, “aB”, or “ab”.

3.7. Deprecated Option Aliases

Certain OpenSignature rule options can be specified using an alias name. Avoid using aliases, they are deprecated and will be removed in a future release. When analias is encountered in a rule, a warning message is issued.

Final 19


DeprecatedName

Option Name

data.integer byte_test

icmp.code icode

icmp.id icmp_id

icmp.seq icmp_seq

icmp.type itype

ip.dsize dsize

ip.flags fragbits

ip.fragoffset fragoffset

ip.id id

ip.proto ip_proto

ip.sameip sameip

ip.tos tos

ip.ttl ttl

tcp.ack ack

tcp.seq seq

tcp.window window

Table 3.3: Deprecated Option Aliases

Final 20


4. Configuration Reference

4.1. Statement Grammar

Each rule must be complete when the parser reaches the end of its input line. The lines that define rules are described using a pseudo EBNF notation with the following conventions:

Productions using ':=' operators are grammar productions consisting of a left hand non-terminal symbol and a sequence of right hand terminal and non-terminal symbols.

A grammar production with an empty left hand non-terminal symbol represents an alternative production for the last non-terminal with a non empty left hand symbol.

Productions using '::' operators are POSIX regular expressions describing allowable terminal string content.

A comma indicates concatenation of adjoining symbols. Text enclosed in quotation marks are literal terminal strings. Text enclosed by '(*' and '*)' sequences are comments. Text enclosed by question marks represent EBNF extensions. OpenSignature

utilizes the following extension phrases.

Extension Phrase Description

? ipv4 ? A single IPV4 address in standard notation.

? ipv6 ? A single IPV6 address in standard notation.

? adapter name ? A logical interface name. This token must resolve to an adapter number using a PAM advanced tuning parameter.

? end of statement ? Every statement is described in a single unique logical line. The definition of a logical line is implementation dependent.

Final 21


configuration := statement:= statement configuration

statement := statement_type ? end of statement ?

statement_type := variable_decl:= config_decl:= rule

variable_decl := “var” variable_name TOKEN:= “portvar” variable_name port_expr:= “ipvar” variable name endpoint_expr

TOKEN :: [^[:space:]]+

config_decl := “config” “:” config_clauses

config_clauses := config_clause:= config_clause config_clauses

config_clause := “interface” “:” interface_list

interface_list := interface:= interface “,” interface_list

interface := ? adapter name ?

rule := action filter_expr:= action filter_expr “(“ rule_options “)”

action := “alert”:= “log”:= “pass”:= “activate”:= “dynamic”:= “drop”:= “reject”:= “sdrop”

filter_expr := protocol source direction destination

protocol := “ip”:= “icmp”:= “udp”:= “tcp”

source := endpoint (* packet source *)

direction := “->” (* directional rule *):= “<>” (* non-directional rule *)

destination := endpoint (* packet destination *)

endpoint := endpoint_expr port_expr

endpoint_expr := “any”:= address_expression

port_expr := “any”:= port_expression

port_expression := port_sequence:= “!”, port_sequence

Final 22


port_sequence := port:= port-range:= port-list

port := INTEGER (* 0 <= port < 65536 *)

port-range := low, “:”, high (* low <= port <= high *):= low, “:” (* low <= port *):= “:”, high (* high >= port *)

port_list := “[“, port_items, “]”

port_items := port_expression:= port_expression, “,”, port_items

address_expression := address_sequence:= “!”, address_sequence

address_sequence := address:= address_block:= address_range:= address_list

address_block := address, “/”, cidr

address_range := address, “-”, address

address_list := “[“, address_items, “]”

address_items := address_expression:= address_expression, “,”, address_items

address := ? ipv4 ?:= ? ipv6 ?

cidr := INTEGER (* 0 < cidr <= (ipv4? 32: 128) *)

rule_options := option_types rule_options

option_types := general_options:= payload_options:= packet_options:= postdetect_options

general_options := classtype:= gid:= metadata:= msg:= priority:= reference:= rev:= sid

Final 23


payload_options := asn1:= byte_jump:= byte_test:= content:= depth:= distance:= file_data:= http_client_body:= http_cookie:= http_header:= http_hostname:= http_method:= http_raw_uri:= http_stat_code:= http_stat_msg:= http_uri:= http_user_agent:= isdataat:= nocase:= offset:= pam_context:= pcre:= pkt_data:= rawbytes:= ssl_state:= ssl_version:= uricontent:= urilen:= within

packet_options := ack:= dsize:= flags:= flow:= flowbits:= fragbits:= fragoffset:= icmp_id:= icmp_seq:= icode:= id:= ip_proto:= ipopts:= itype:= sameip:= seq:= tos:= ttl:= window

postdetect_options := tag:= threshold

4.2. Rule Option Grammar

Final 24


4.2.1. ack

Syntax

ack := “ack” “:” seqno “;”

seqno := INTEGER (* 0 <= seqno < 2**32 *)

INTEGER :: [0-9]+

Description

Matches TCP packets (only) which contain a specific TCP acknowledgment number.

Example

alert tcp any any -> any any (ack:7426305;)

4.2.2. asn1

OpenSignature parses the asn1 keyword but does not implement its semantics.

4.2.3. byte_jump

Syntax

byte_jump := “byte_jump” “:” width ',' offset [ ',' “relative” ] [ ',' “multiplier” multiplier ]

[ ',' “post_offset” post_offset ] [ ',' format ] [ ',' “align” ] [ ',' “from_beginning” ] “;”

width := NUMBER (* 1 <= width <= 10 *)

offset := NUMBER (* -65535 <= offset <= 65535 *)

post_offset := NUMBER (* -65535 <= post_offset <= 65535 *)

multiplier := NUMBER (* 0 <= multiplier <= 65535 *)

format := “big” (* big endian, MSB to LSB *):= “little” (* little endian, LSB to MSB *):= “string” “,” radix (* convert string *)

radix := “hex” (* base 16 string *):= “oct” (* base 8 string *):= “dec” (* base 10 string *)

Description

Allows rules that skip over portions packets based on numeric values in the packet data itself. The byte_test section (below) describes the option arguments.

Final 25


Example

alert ip any any -> any any ( byte_jump:4,7,relative,from_beginning; )

4.2.4. byte_test

Syntax

byte_test := “byte_test” “:” width ',' test ',' argument ',' offset [ ',' “relative” ] [ ',' format ] “;”

width := NUMBER (* 1 <= width <= 10 *)

argument := NUMBER (* 0 <= argument <= 4294967295 *)

offset := NUMBER (* -65535 <= offset <= 65535 *)

test := [ “!” ] “=” (* [not] equal *):= [ “!” ] “<” (* [not] less than *):= [ “!” ] “>” (* [not] greater than *):= [ “!” ] “&” (* [bit-wise AND is [not] non-zero *):= [ “!” ] “^” (* [bit-wise XOR is [not] non-zero *)

format := “big” (* big endian, MSB to LSB *):= “little” (* little endian, LSB to MSB *):= “string” “,” radix (* convert string *)

radix := “hex” (* base 16 string *):= “oct” (* base 8 string *):= “dec” (* base 10 string *)

Description

Allows rules to implement “typed” comparisons of integers. The width symbol identifies the number of octets in the packet to process. The test symbol identifies the specific comparison operation desired:

VALUE provides one operand, while the BYTES_TO_CONVERT octets at OFFSET in the packet provide the other. If the rule specifies the RELATIVE keyword, then OFFSET counts from the most recent pattern match; otherwise it counts from the start of the packet.

The BIG and LITTLE arguments allow the rule to specify the “endianness” to be used when converting the octets from the packet into an integer. Most network protocols use BIG endian format. Application protocols could use either, particularly ones developed first or exclusively on little-endian platforms like Intel's IA32 and IA64.

The STRING argument allows the rule to compare the integer in the rule with an integer converted from text in the packet data. The HEX, DEC, and OCT arguments specify the method the rule should use to convert the text into an integer (hexadecimal, decimal, or octal, respectively). If unspecified, the rule assumes DEC (decimal) formatting of the text in the packet.

Final 26


Example

alert ip any any -> any any ( byte_test:4,equals,17; )

alert ip any any -> any any ( byte_test:4,equals,17,16,little,string,hex; )

4.2.5. classtype

Syntax

classtype := “classtype” “:” NAME “;”

Description

Allows the author to categorize the type of attack that the rule detects. OpenSignature does not provide the default classtype values that Snort provides. However, signature authors can use those classtype values, or others, if desired. OpenSignature will accept any argument to this option. Common examples include trojan-activity, policy-violation, shellcode-detect, misc-attack, and misc-activity.

In Snort, different classtype values imply specific priority values for the events. In OpenSignature, they do not, and the signature author must explicitly include a priority option if desirous of a non-default priority for the rule.

Example

alert ip any any -> any any ( classtype:shellcode-detect; )

4.2.6. content

Syntax

content := “content” “:” [“!”] CONTENT_STRING “;”

CONTENT_STRING = “(\|[0-9a-fA-F ]+\|)|(\\[“\\:;|])|[^”\\:;|])+”

Description

The content option implements the most common method to match specific text (case sensitively) in the packet payloads. This option provides literal matching of strings of adjacent octets in the packet payload. Rules requiring more complex text matching capabilities can use the pcre option to access regular expressions. Rules more interested in HTTP request URIs can use the uricontent option.

The TEXT argument may contain “regular” text data, or binary data, or both. The first example specifies a simple text match. If the packet payload contains the literal text “yahoo” (case sensitive) then this option matches. The second example illustrates the second major form: binary data represented as hexadecimal numbers in text. The third example shows how to mix them in a single argument.

Final 27


At the beginning of the TEXT argument, the parser assumes the following characters represent text characters directly, as in the first example. When it encounters a “pipe” or “vertical bar” character ('|'), it starts interpreting the text as pairs of hexadecimal digits. It takes consecutive pairs of octets and converts them to data bytes from hexadecimal. When it reaches another “pipe” character, it reverts to interpreting the input as directly-represented text characters. The final “pipe” character may be omitted if no directly-represented characters follow it in the argument.

When interpreting the characters as hexadecimal digits, the parser acts case-insensitively; it accepts the lower-case 'a' through 'f' as well as the upper case 'A' through 'F' as hexadecimal digits. Spaces can appear between the pairs of hexadecimal digits, but not within the pairs.

The final two examples illustrate the “escaping” necessary for certain characters used in content option arguments. The following characters must be “escaped” by preceding them with a backslash ('\') character: colon (':'), semicolon (';'), backslash ('\'), double quotation ('”'), and “pipe” or “vertical bar” ('|').

The following options modify content rules: depth, offset, distance, within, nocase, and (unsupported) rawbytes. Absent any options, the search for the argument applies to the entire payload of TCP and UDP protocol packets.

Final 28


Example

alert tcp any any -> any any ( content:”yahoo”; )

alert tcp any any -> any any ( content:”|00 01 02 03 04|”; )

alert tcp any any -> any any ( content:”y|61 68|oo”; )

alert tcp any any -> any any ( content:!”yahoo”; )

alert tcp any any -> any any ( content:”content-encoding\: UTF-8”; )

alert tcp any any -> any any ( content:”\:\;\\\”\|”; )

4.2.7. depth

Syntax

depth := “depth” “:” value “;”

value := INTEGER (* 1 <= count <= 65535 *)

INTEGER :: [0-9]+

Description

Specify how many octets of the packet's payload the rule should inspect seeking a match. The example instructs the OpenSignature engine to compare only the first ten octets of the packet's payload to the rule. The OpenSignature engine applies rules without depth specifications to the entire packet payload.

Example

alert tcp any any -> any any ( content:”|00 FF|”; depth:10; )

4.2.8. distance

Syntax

distance := “distance” “:” value “;”

value := INTEGER (* -65535 <= value <= 65535 *)

INTEGER :: (+|-){0,1}[0-9]+

Description

Specify how many octets of the packet payload to skip before seeking the pattern. The distance counts relative to the end of the previous pattern match. The distance option acts similarly to the offset option, but relative to the previous pattern match, rather than the beginning of the packet payload.

Final 29


Example

alert tcp any any -> any any ( content:”ab”; content:”cd”; distance:10; )

4.2.9. dsize

Syntax

dsize := “dsize” “:” constraint “;”

constraint := [ “<” | “>” ] size (* less than | greater than *):= size “<>” size (* range *)

size := INTEGER (* 1 <= size <= 65535 *)

INTEGER :: [0-9]+

Description

Matches the payload size of the packet. The first example matches IP packets that are exactly 300 octets in size. The second example matches IP packets containing less than 300 octets. The third matches IP packets containing 301 to 399 octets. Thefourth example matches packets containing more than 400 octets.

Example

alert ip any any -> any any ( dsize:300; )

alert ip any any -> any any ( dsize:<300; )

alert ip any any -> any any ( dsize:300<>400; )

alert ip any any -> any any ( dsize:>400; )

4.2.10. file_data

Syntax

file_data := “file_data” “;”

Description

Switches the context for payload inspection in the current rule from packet data to file entities transferred by protocols such as http and others. Unlike other modifiers, file_data applies to subsequent payload tests or until pkt_data context is restored.

Final 30


Example

alert tcp any any -> any any ( file_data; content:”<some_xml_tag>”; )

4.2.11. flags

Syntax

flags := “flags” “:” match [ “,” ignore ] “;”

tcpbits := “a” | “A” (* ack *):= “c” | ”C” | ”1” (* cwr *):= “e” | ”E” | ”2” (* ecn *):= “F” (* fin *):= “P” (* psh *):= ”R” (* rst *):= ”S” (* syn *):= ”U” (* urg *)

modifier := (* exact *):= “!” (* not *):= “*” (* any of *):= “+” (* only *)

check := “0” (* none *):= tcpbits (* tcp flag *):= modifier (* test modifier *)

match := check [ , ?{ match }? ] (* at most 1 of each flag *)

ignore := tcpbits [ , ?{ ignore }? ] (* at most 1 of each flag *)

Description

Tests the flag bits in TCP protocol packet headers. Matches packets that contain a specific set of TCP header flags.

As with any other keyword, the '!' operator indicates negation (i.e., the flag bit is not set). The '*' operator indicates that at least one of the specified flags must be set in the packet to match. The '+' operator indicates that at least the specified flags must be set in the packet.

A rule can test more than one flag bit at once by including more than one flag bit identifier in the rule. Normally, the flags are “or-ed” together, progressing left to right. When the argument includes the comma (',') operator, the rule negates the following flags rather than asserting them. A second comma returns to asserting flags, a third to negating, etc.

Final 31


Example

alert tcp any any -> any any ( flags:SF+,12; )

4.2.12. flow

Syntax

flow := “flow” “:” tests “;”

dir := “to_client” | “from_server”:= “from_client” | “to_server”

state := “established” | “stateless”

stream := “no_stream” | “only_stream”

tests := state | dir | stream [ “,” ?{ tests }? ]

Description

This option establishes the rule's intent to track traffic only in certain directions. The indicated arguments to the flow option have the following effects:

Option Behavior

to_client Match server responses from A to B.

to_server Match client requests from A to B.

from_client Match client requests from A to B.

from_server Match server responses from A to B.

established Match only on established TCP connections.

stateless Match regardless of the establishment state of the TCP stream. This option is useful for packets designed to crash hosts.

no_stream Do not match on rebuilt stream packets (useful for dsize and stream options).

only_stream Only match on rebuilt stream packets.

Table 4.1: OpenSignature arguments for the flow option.

Final 32


Example

alert tcp any any -> any any ( flow:to_server; )

4.2.13. flowbits

Syntax

flowbits := “flowbits” “:” action “;”

action := flagops “,” flags [ “,” group ]:= “reset” [ “,” group ]:= “noalert”

flagops := “set” (* set flag(s) *):= “setx” (* set flags(s) exclusively *):= “unset” (* reset flag(s) *):= “toggle” (* invert flag(s) *):= “isset” (* test for set *):= “isnotset” (* test for unset *)

flags := “all” (* synonym for all flags *):= NAME (* flag name *):= or (* flag or expression *):= and (* flag and expression *)

or := NAME [ , “|” or ]

and := NAME [ , “&” and ]

group := NAME (* group id *)

NAME :: [a-zA-Z0-9._-]+

Description

This option allows sets of rules to accumulate and share persistent state information associated with flows in a transport protocol session.

The STATE argument names the state. It takes author-specified values that are convenient for the rule set. The STATE argument may contain alphabetic characters, digit characters, periods ('.'), dashes ('-'), and underscores ('_'). Each state may attain the values of “set” or “not set”/”clear”. The argument keywords operate on that STATE each time the rule triggers.

Final 33


Option Behavior

set Sets the specified state for the current flow.

unset Clears the specified state for the current flow.

toggle Clears the specified state if set, or sets it if cleared.

isset Checks whether the state is set.

isnotset Checks whether the state is clear (not set).

noalert Prevents the rule from generating an event regardless of the matching state of the rest of the rule.

Table 4.2: OpenSignature arguments for the flowbits option.

Example

alert tcp any any -> any any ( flowbits:set,login; )

alert tcp any any -> any any ( flowbits:unset,login; flowbits:noalert; )

4.2.14. fragbits

Syntax

fragbits := “fragbit” “:” [test,] bits “;”

test := “+” (* all bits present plus others *):= “*” (* at least one bit present *):= “!” (* no bits present *)

bits := “M” (* more fragments *):= “D” (* don't fragment *):= “R” (* reserved bit *)

Description

Matches packets based on the fragmentation control bits in the IP protocol header. The option recognizes the following flag bit identifiers:

M – More Fragments flag. D – Don't Fragment flag. R – Reserved flag.

The option also recognizes the following modifiers for the flags:

+ – Require these bits to be set * – Require at least one of these bits to be set ! – None of these bits must match

Final 34


Example

alert ip any any -> any any ( fragbits:+MD; )

alert ip any any -> any any ( fragbits:!R; )

4.2.15. fragoffset

Syntax

fragoffset := “fragoffset” “:” condition value “;”

condition := “!” (* not equal *):= “<” (* less than *):= “>” (* greater than *)

value := INTEGER (* 0 <= value <= 65535 *)

INTEGER :: [0-9]+

Description

Matches packets with a specific value for the “fragment offset” field of the IP protocolheader. The first two examples match packets for which the IP fragmentation offset is exactly 100. The third example inverts the first two, matching only packets with thefragmentation offset not equal to 100. The fourth and fifth examples match packets with the fragmentation offset less than or equal to 100 (fourth) and not greater than or equal to 100 (fifth).

Final 35


Example

alert ip any any -> any any ( fragoffset:100; )

alert ip any any -> any any ( fragoffset:!100; )

alert ip any any -> any any ( fragoffset:<100; )

alert ip any any -> any any ( fragoffset:!>100; )

4.2.16. gid

Syntax

gid := “gid” “:” generator “;”

generator := INTEGER (* 1 <= generator < 2**32, ignored *)

INTEGER :: [0-9]+

Description

Present for rule syntax compatibility; generator ids are often specified for other rule based intrusion detection systems. OpenSignature uses the value only for event decoration.

Example

alert ip any any -> any any ( gid:7426305; )

4.2.17. http_client_body

Syntax

http_client_body := “http_client_body” “;”

Description

Restricts the preceding content search to the context of the message body following the headers of an HTTP request.

Final 36


Example

alert tcp any any -> any any ( content:“<html>”; http_client_body; )

4.2.18. http_cookie

Syntax

http_cookie := “http_cookie” “;”

Description

Restricts the preceding content search to the context of normalized HTTP cookie values. For HTTP requests, this would be the normalized value of the “Cookie:” header field. For HTTP responses, the normalized value of the “Set-Cookie:” headerfield is used.

Example

alert tcp any any -> any any ( content:”8378502”; http_cookie; )

4.2.19. http_header

Syntax

http_header := “http_header” “;”

Description

Restricts the preceding content search to the context of HTTP request and responseheaders. This matches the entire header body from the very first header to the very last header including all header name, values, and white space.

Example

alert tcp any any -> any any ( content:“Cache”; http_header; )

4.2.20. http_hostname

Syntax

http_hostname := “http_hostname” “;”

Description

Restricts the preceding content search to the effective hostname for HTTP requests. This will match the hostname in a proxy request if present, otherwise the value of theHost header.

This is an OpenSignature extension keyword.

Final 37


Example

alert tcp any any -> any any ( content:“somehost.com”; http_hostname; )

4.2.21. http_method

Syntax

http_method := “http_method” “;”

Description

Restricts the preceding content search to the context of HTTP request methods (ex. GET, POST, HEAD, etc).

Example

alert tcp any any -> any any ( “content:”GET”; http_method; )

4.2.22. http_raw_uri

Syntax

http_raw_uri := “http_raw_uri” “;”

Description

Restricts the preceding content search to the context of raw HTTP URIs. Unlike http_uri, http_raw_uri will perform pattern matching against the unnormalized bytes in the URI as seen on the wire.

Example

alert tcp any any -> any any ( content:“&arg=value”; http_raw_uri; )

4.2.23. http_stat_code

Syntax

http_stat_code := “http_stat_code” “;”

Description

Restricts the preceding content search to the context of the message body following the headers of an HTTP request. OpenSignature processes this modifier differently: the content search is transformed into a numeric test. This will lead to rule incompatibility if a partial content string match is attempted.

Final 38


Example

alert tcp any any -> any any (content:“404”; http_stat_code; )

4.2.24. http_stat_msg

Syntax

http_stat_msg := “http_stat_msg” “;”

Description

Restricts the preceding content search to the HTTP response status message.

Example

alert tcp any any -> any any ( content:“Found”; http_stat_msg; )

4.2.25. http_uri

Syntax

http_uri := “http_uri” “;”

Description

Restricts the preceding content search to the context of HTTP URIs. As the HTTP parser in PAM reads and normalizes the URI in an HTTP request, OpenSignature will attempt to match the specified pattern against the decoded URI.

Example

alert tcp any any -> any any ( content:”index.html”; http_uri; )

4.2.26. http_user_agent

Syntaxhttp_user_agent := “http_user_agent” “;”

Description

Restricts the preceding content search to the user agent string within HTTP requests. This is an OpenSignature extension keyword.

Final 39


Examplealert tcp any any -> any any ( content:”Mozilla”; http_user_agent; )

4.2.27. icmp_id

Syntax

icmp_id := “icmp_id” “:” value “;”

value := INTEGER (* 0 <= icmp_id <= 65535 *)

INTEGER :: [0-9]+

Description

Matches ICMP packets that have an exact value for the ID field in their protocol headers. Not all ICMP packet types contain an id field.

Example

alert icmp any any -> any any ( icmp_id:1956; )

4.2.28. icmp_seq

Syntax

icmp_seq := “icmp_seq” “:” value “;”

value := INTEGER (* 0 <= icmp_seq <= 65535 *)

INTEGER :: [0-9]+

Description

Matches packets with specific values for the sequence number field in ICMP protocol headers.

Final 40


Example

alert icmp any any -> any any ( icmp_seq:256; )

4.2.29. icode

Syntax

icode := “icode” “:” expr “;”

expr := min “<>” max (* range test *):= “<” value (* icode < value *):= “>” value (* icode > value *):= value (* icode = value *)

min := value (* min <= max *)

max := value (* min <= max *)


INTEGER :: [0-9]+

Description

Matches packets based on the value of the “ICMP Code” field of the ICMP protocol header. The first example matches only ICMP packets with the “code” field set to four. The second matches packets with the “code” set to values greater than four. The third example matches packets with the “code” set to values greater than four and less than seventeen.

Example

alert icmp any any -> any any ( icode:4; )

alert icmp any any -> any any ( icode:>4; )

alert icmp any any -> any any ( icode:<4; )

alert icmp any any -> any any ( icode:4<>17; )

4.2.30. id

Syntax

id := “id” “:” value “;”


INTEGER :: [0-9]+

Description

Checks the Identification field of the packet's IP header for a specific value. Various tools (exploits, scanners, and other programs) set this field for different purposes.

Final 41


Example

alert ip any any -> any any ( id:12345; )

4.2.31. ip_proto

Syntax

ip_proto := “ip_proto” “:” [not] protocol “;”

not := “!”

protocol := NAME (* symbolic protocol name *):= [ relation ] INTEGER (* 0 <= protocol <= 255 *)

relation := “<” (* less than *):= “>” (* greater than *)

NAME :: [a-zA-Z0-9_]+

INTEGER :: [0-9]+

Description

Compares the protocol field in an IP packet header to a specific value or name. The NAME argument to this option may be ip, icmp, udp, or tcp.

Final 42


Example

alert ip any any -> any any ( ip_proto:17; )

alert ip any any -> any any ( ip_proto:!17; )

alert ip any any -> any any ( ip_proto:<17; )

alert ip any any -> any any ( ip_proto:tcp; )

4.2.32. ipopts

Syntax

ipopts := “ipopts” “:” options “;”

options := “rr” (* record route *):= “eol” (* end of list *):= “nop” (* no operation *):= “ts” (* time stamp *):= “sec” (* ip security *):= “esec” (* ip extended security *):= “lsrr” (* loose source routing *):= “lsrre” (* non-standard value 132 *):= “ssrr” (* strict source routing *):= “satid” (* stream identifier *):= “any” (* any option *)

Description

Matches packets based on the presence of IP protocol options. Note that only one ipopts option may appear in an OpenSignature rule!

Final 43


Example

alert ip any any -> any any ( ipopts:rr; )

4.2.33. isdataat

Syntax

isdataat := “isdataat” “:” expr “;”

expr := [ not ] offset [ relative ]

not := “!” (* match on test false *)

offset := INTEGER (* 0 <= offset <= 65535 *)

relative := “,” “relative”

INTEGER :: [0-9]+

Description

This option verifies that the packet payload has data at a specified offset within the payload portion of the packet. Without the RELATIVE argument, NUMBER specifies an offset from the beginning of the packet payload. With the RELATIVE argument, however, NUMBER measures from the location of the previous match.

Example

alert udp any any -> any any ( isdataat:12345; )

alert udp any any -> any any ( isdataat:!12345,relative; )

4.2.34. itype

Syntax

itype := “itype” “:” expr “;”

expr := min “<>” max (* range test *):= “<” value (* itype < value *):= “>” value (* itype > value *):= value (* itype = value *)

min := value (* min <= max *)

max := value (* min <= max *)


INTEGER :: [0-9]+

Description

Matches ICMP packets based on the “ICMP Type” field in the protocol header.

Final 44


Example

alert icmp any any -> any any ( itype:13; )

alert icmp any any -> any any ( itype:<9; )

alert icmp any any -> any any ( itype:>99; )

alert icmp any any -> any any ( itype:4<>10; )

4.2.35. metadata

Syntaxmetadata := “metadata” “:” expr “;”

expr := key_value:= key_value “,” expr

key_value := “service” service_list := ignore

service_list := service:= service service_list

service := NAME (* protocol name *)

ignore := SKIP (* anything other than service *)

NAME :: [a-zA-Z0-9_]+

SKIP :: [^;]+

Description

The service form is used to match a recognized protocol name. Matching a protocol in this way enables a rule to leverage PAM protocol heuristics and match protocol flows involving non-standard server endpoints. This capability applies only to TCP rules.

The ignore form ignores all tokens until the next comma or end of option, this variation has no effect on the rule.

Final 45


Examplealert tcp any any -> any any ( metadata:service http ftp; )

4.2.36. msg

Syntax

msg := “msg” “:” QUOTED “;”

QUOTED :: [“](\[\:;”]|[^\:;”])*[“]

Description

This option provides a textual message for PAM events produced when the rule triggers. Typically, the text describes the detection in a way that allows the system operator to respond appropriately. The message text appears in the Attribute-Value Pairs (AVPs) of the event.

The second example illustrates the “escaping” necessary for certain characters when used in a msg option argument. To include the following characters in the actual message text, the rule definition must “escape” them by preceding them with a backslash ('\') character: colon (':'), semicolon (';'), backslash ('\'), double quotation ('”'). The second example uses this technique to embed two double quotation marks into the message text, as shown in the comment.

Example

alert ip any any -> any any ( msg:”Yahoo Mail Detected!”; )

alert ip any any -> any any ( msg:”Yahoo\: \”You've Got Mail\””; )

4.2.37. nocase

Syntax

nocase := “nocase” “;”

Description

Modifies the preceding content/uricontent match to ignore letter case during comparison. OpenSignature does not support locales or Unicode, so this applies to US-ASCII upper and lower case character codes.

Final 46


Example

alert tcp any any -> any any ( content:”GeT”; http_method; nocase; )

4.2.38. offset

Syntax

offset := “offset” “:” value “;”


INTEGER :: [0-9]+

Description

Modifies the preceding content match to begin at the indicated offset within the payload. For example, an offset of ten indicates that the engine should skip the first ten octets of the payload, then begin seeking the pattern. The offset option is similar to the distance option, but is relative to the beginning of the packet payload, rather than the previous pattern match.

Example

alert udp any any -> any any ( content:“hello”; offset:100; )

4.2.39. pam_context

Syntax

pam_context := “pam_context” “:” context_name “;”

context_name := NAME (* PAM parsed data name *)

NAME :: [a-zA-Z0-9_]+

Description

Restricts the preceding content search to data reported by a PAM parser. This is an OpenSignature extension keyword. The following context names are available:

4.2.39.1. content_javascript

The preceding content clause is matched against the contents of JavaScript, which may appear in either a standalone JavaScript file or within JavaScript code embedded within an HTML or PDF entity.

4.2.39.2. content_pdf

The preceding content clause is matched against the contents of files within a PDF entity.

Final 47


4.2.39.3. dns_aaaa_query

The preceding content clause is matched against DNS 'AAAA' record queries.

4.2.39.4. dns_any_query

The preceding content clause is matched against DNS 'ANY' record queries.

4.2.39.5. dns_cname_query

The preceding content clause is matched against DNS 'CNAME' record queries.

4.2.39.6. dns_hinfo_query

The preceding content clause is matched against DNS 'HINFO' record queries.

4.2.39.7. dns_mx_query

The preceding content clause is matched against DNS 'MX' record queries.

4.2.39.8. dns_naptr_query

The preceding content clause is matched against DNS 'NAPTR' record queries.

4.2.39.9. dns_ns_query

The preceding content clause is matched against DNS 'NS' record queries.

4.2.39.10. dns_ptr_query

The preceding content clause is matched against DNS 'PTR' record queries.

4.2.39.11. dns_query

The preceding content clause is matched against DNS 'A' record queries.

4.2.39.12. dns_soa_query

The preceding content clause is matched against DNS 'SOA' record queries.

4.2.39.13. dns_srv_query

The preceding content clause is matched against DNS 'SRV' record queries.

4.2.39.14. dns_txt_query

The preceding content clause is matched against DNS 'TXT' record queries.

4.2.39.15. email_receiver

The preceding content clause is matched against the EMAIL receiver (to:) data.

Final 48


4.2.39.16. email_sender

The preceding content clause is matched against EMAIL sender (from:) data.

4.2.39.17. email_subject

The preceding content clause is matched against email subject (subject:) data.

4.2.39.18. file_content

The preceding content clause is matched against file content.

4.2.39.19. file_name

The preceding content clause is matched against file names.

4.2.39.20. http_form_data_raw

The preceding content clause is matched against strings in HTTP POST sessions transmitting 'application/x-www-form-urlencoded' data. The data that will be searched is the entire, non-normalized name/value pair string sent by the POST request.

4.2.39.21. mms_mm1

The preceding content clause is matched against MMS MM1 data.

4.2.39.22. news_group

The preceding content clause is matched against the argument to the NNTP 'GROUP' command.

4.2.39.23. password

The preceding content clause is matched against passwords seen by PAM.

4.2.39.24. rpc_request

The preceding content clause is matched against RPC Requests.

4.2.39.25. rtmp_stream_name

The preceding content clause is matched against an RTMP Stream Name in the

\play\ and \play2\ commands.

4.2.39.26. smtp_command

The preceding content clause is matched against SMTP commands.

Final 49


4.2.39.27. snmp_community

The preceding content clause is matched against SNMP community strings.

4.2.39.28. tls_server_name

The preceding content clause is matched against a TLS server name.

4.2.39.29. url_data

The preceding content clause is matched against URL get data.

4.2.39.30. url_post_data

The preceding content clause is matched against URL post data.

4.2.39.31. url_raw_data

The preceding content clause is matched against raw URL get data.

4.2.39.32. url_raw_post_data

The preceding content clause is matched against raw URL post data.

4.2.39.33. url_user_agent_data

The preceding content clause is matched against user agent strings in various protocols.

4.2.39.34. user_login_name

The preceding content clause is matched against user login names using the following protocols: FTP, HTTP, IMAP, NNTP, POP3, REXEC, RLOGIN, RSH, SMB, TELNET.

4.2.39.35. user_probe_name

The preceding content clause is matched against user name probes from various sources.

4.2.39.36. voip_call

The preceding content clause is matched against protocol buffers identifying

and classifying Voice over IP (VoIP) calls. Each time a calling device

initiates a call, the device generates a \Request to Communicate\ message

regardless of the protocol type (i.e., H.323, SIP, or Cisco SCCP). The signature

extracts the called URI or phone number and compares against list of user defined

filters.

Final 50


The filter's match expression must be tailored to an organization's

VoIP protocol and callers address type. SIP defined in RFC 3261 uses

a URI. H.323 defined by International Telegraph Union (ITU) uses a Host Address

and Phone Number. Cisco SCCP, a proprietary protocol, uses a Host Address.

Phone Number - phone number is a sequence of digits that may have hyphen

separators.

URI - a User@Host_Address defines how to contact a callee or called party.

The URI format is specified by RFC 2396. Examples of format are: [email protected]:2194,

+1-222-3333-4444, [email protected]

Host Address - A host address defines how to contact or respond to callee's \Request

for Communication\ message. The address can be either a TCP/UDP address

or DNS name.

4.2.39.37. x509_in_file

The preceding content clause is matched against 5 key fields within a

file-based X.509 Certificate (e.g. within Authenticode data).

Note that this user-defined event may be used to identify and block almost any

certificate based on the combination of Issuer and Serial Number.

The 5 key certificate fields that may be matched are always listed in the following

order, with a two-byte delimiter of \||\ (vertical bars, 0x7c7c) between fields,

and with 3-letter identifiers for the name fields:

[serialNumber (converted from binary to hexadecimal)]

iCN=[issuer commonName]

iON=[issuer organizationName]

sCN=[subject commonName]

sON=[subject organizationName]

As the Serial Number is binary data, it is reported in hexadecimal (uppercase).

For example, if a certificate has a four-byte Serial Number value of F5 00 1C 3A,

Final 51


is missing issuer commonName, has an issuer organizationName of \Authority\, has a

subject commonName of \foo.com\ and a subject organizationName of \Fooey\,

the resulting data for matching would be either of the following ASCII strings,

depending on whether Subject field matching is desired:

F5001C3A||iCN=||iON=Authority||sCN=foo.com||sON=Fooey

F5001C3A||iCN=||iON=Authority

4.2.39.38. x509_in_session

The preceding content clause is matched against 5 key fields within a

session-based X.509 Certificate (e.g. within SSL, TLS, ISAKMP sessions).

Note that this user-defined event may be used to identify and block almost any

certificate based on the combination of Issuer and Serial Number.

Also note that enabling this event may have a slight performance impact of as it

will disable the server certificate caching functionality that skips cleanly parsed

certificates. (See tune pam.tls.server.cert.filter.size for more information.)

The 5 key certificate fields that may be matched are always listed in the following

order, with a two-byte delimiter of \||\ (vertical bars, 0x7c7c) between fields,

and with 3-letter identifiers for the name fields:

[serialNumber (converted from binary to hexadecimal)]

iCN=[issuer commonName]

iON=[issuer organizationName]

sCN=[subject commonName]

sON=[subject organizationName]

As the Serial Number is binary data, it is reported in hexadecimal (uppercase).

For example, if a certificate has a four-byte Serial Number value of F5 00 1C 3A,

is missing issuer commonName, has an issuer organizationName of \Authority\, has a

subject commonName of \foo.com\ and a subject organizationName of \Fooey\,

the resulting data for matching would be either of the following ASCII strings,

depending on whether Subject field matching is desired:

Final 52


F5001C3A||iCN=||iON=Authority||sCN=foo.com||sON=Fooey

F5001C3A||iCN=||iON=Authority

4.2.40. pcre

Syntax

pcre := “pcre” “:” [ not ] QUOTE , regex , QUOTE “;”

not := “!” (* true if regex not matched *)

regex := “/” , STANDARD , “/” , options:= “m” , DELIM , OVERRIDE , DELIM , options

expr := ANY_BUT_DELIM

options := option [ , ?{ options }? ]

option := “i” (* ignore case *):= “s ” (* include newlines in '.' *):= “m ” (* ^ and $ use newlines *):= “x ” (* ignore pattern whitespace *):= “A ” (* match at start of buffer *):= “E ” (* $ match only at end of buffer *):= “G” (* invert greediness *):= “R” (* relate to end of last match *):= “U” (* match normalized http URI *):= “I” (* match unnormalized http URI *):= “H” (* match http headers *):= “M” (* match http method *):= “C” (* match http cookie *):= “P” (* match http client body *)

QUOTE :: [“]

DELIM :: .

STANDARD :: [^/]+

OVERRIDE :: [^[DELIM]]+

Description

Provides regular expression matching of payload content using Perl Compatible Regular Expressions. Details on PCRE behavior can be found at the project web sitehttp://www.pcre.org.

Additional InformationOpenSignature processes payload information in a streaming manner, pcre matcheswill fail if a match spans TCP segment boundaries.

Matching with pcre can be very resource intensive. Rules using pcre should also include a content keyword in the rule for best performance.

Test the performance of rules using pcre before deploying them into a production environment.

Final 53

http://www.pcre.org/


PCRE expressions targeting specific contexts (for example, http_uri) must include a content keyword targeting the same context.

Example

alert udp any any - > any any ( pcre:”/[iI][bB][mM]\./H”; )

alert udp any any - > any any ( pcre:”m~[iI][bB][mM]\.~H”; )

alert ip any any -> any any (content:!”0”; pcre:”/FOO/i”; )

alert tcp any any -> any any (content:”GET ”; pcre:”.*\.htm/i”; )

alert tcp any any -> any 80 (content:”google”; pcre:”/\.com/ism”; )

4.2.41. pkt_data

Syntax

pkt_data := “pkt_data” “;”

Description

Use pkt_data to restore subsequent payload inspection to the transport payload buffer. Since this is the default mode for a rule, the only time this option is useful is toreverse a preceding file_data option.

Example

alert tcp any any -> any any ( file_data; content:”<some_xml_tag>”; pkt_data; content:”Content-Length:”; )

4.2.42. priority

Syntax

priority := “priority” “:” QUOTE priority_value QUOTE “;”

priority_value := “low”:= “medium”:= “high”

Description

Specifies the priority for events generated when the rule triggers. The option must include exactly one argument, it must be enclosed in double quotation marks, and it must be one of the three values listed above. OpenSignature ignores the case of theargument.

This option differs from Snort syntax and semantics. In Snort syntax, priority takes anumeric argument with a value of one representing the highest priority.

Final 54


Example

alert tcp any any -> any any (content:”foo”; priority:”low”;)

4.2.43. rawbytes

Syntax

rawbytes := “rawbytes” “;”

Description

Not supported, ignored.

4.2.44. reference

Syntax

reference := source “,” identifier “;”

source := NAME

identifier := ID

NAME :: [-a-zA-Z0-9_]+

ID :: [-/?.:=a-zA-Z0-9_]+

Description

Decorates an event with references from external attack identification systems. This option may be repeated to supply multiple references for a single rule. For example, a rule might be associated with reports from Nessus and McAfee as well as a Common Vulnerability Enumeration (CVE) disclosure.

OpenSignature does not validate the operands of this clause in any way. The reference information appears in the Attribute-Value Pairs (AVPs) if an event is generated.

Final 55


Example

alert ip any any -> any any ( content:”foo”;reference:cve,CVE-9999-9999;)

4.2.45. rev

Syntax

rev := “rev” “:” TAG “;”

TAG :: [-/?.:=a-zA-Z0-9_]+

Decorates an event with a revision tag to identify different revisions of a rule. OpenSignature does not validate the operand in any way, revision information is used to decorate generated events. This allows an operator to test different versions of a rule at the same time, while still distinguishing PAM events produced by each.

Example

alert ip any any -> any any (content:”foo”; rev:3;)

4.2.46. sameip

Syntax

sameip := “sameip” “;”

Description

Matches packets in which the source IP address is the same as the destination IP address in the IP packet header.

Example

alert ip any any -> any any (sameip;)

4.2.47. seq

Syntax

seg := “seq” “:” sequence_number “;”

sequence_number := INTEGER

INTEGER :: [0-9]+

Description

Matches packets having a specific value in the sequence number field of the TCP packet header.

Final 56


Example

alert tcp any any -> any any (seq:4532543;)

4.2.48. sid

Syntax

sid := “sid” “:” signature_id “;”

signature_id := INTEGER

INTEGER :: [0-9]+

Description

Each rule may have a Signature Id that is used to associate a rule with an event. The Signature Id must be a non-negative integer. When this value is present and unique it is used as one basis for PAM issue number generation.

Example

alert ip any any -> any any (content:”foo”; sid:1000;)

4.2.49. ssl_state

Syntax

ssl_state := “ssl_state” “:” state_expression “;”

state_expression := state_list (* positive match *):= “!” state_list (* negative match *)

state_list := state_name:= state_name “,” state_list

state_name := “client_hello”:= “server_hello”:= “client_keyx”:= “server_keyx”:= “unknown”

Description

Matches SSL/TLS records based on the SSL/TLS handshake state. The match can be negated with “!”. Multiple states in a comma delimited list are logically ORed for comparison.

Final 57


Example

alert tcp any any -> any any (ssl_state:client_keyx,server_keyx;)

4.2.50. ssl_version

Syntax

ssl_version := “ssl_version” “:” version_expression“;”

version_expression := version_list (* positive match *):= “!” version_list (* negative match *)

version_list := version:= version “,” version_list

version := “sslv2”:= “sslv3”:= “tls1.0”:= “tls1.1”:= “tls1.2”

Description

Matches SSL/TLS records based on the SSL/TLS version number. The match can be negated with “!”. Multiple version numbers in a comma delimited list are logically ORed for comparison.

Final 58


Example

alert tcp any any -> any any (ssl_version:!tls1.0,tls1.1,tls1.2;)

4.2.51. tag

Syntax

tag := “tag” “:” tag_expr “;”

tag_expr := “host” host_expr (* track by host *):= “session” limit (* track by session *)

host_expr := limit “,” direction (* src or dst host *)

limit := “,” count “,” metric (* count and scope *)

metric := “packets” (* limit by packets *):= “seconds” (* limit by seconds *)

direction := “src” (* src packets only *):= “dst” (* dst packets only *)

count := INTEGER

INTEGER :: [0-9]+

Description

Use the tag option to request network sensor logging of additional packets once the rule is triggered. Logging is limited by either packet count or time within the scope of a host address or session. Behavior of this option is dependent on support by the network sensor product. If packet tagging isn't supported by the sensor product, the option will have no effect.

Final 59


Example

alert tcp any any -> any any ( content:”foo”; tag:session,5,packets; )

alert tcp any any -> any any ( content:”foo”; tag:host,3,seconds,src; )

4.2.52. threshold

Syntax

threshold := “threshold” “:” type track events “;”

type := “type” type_keyword “,”

type_keyword := “limit” (* event limiter *):= “threshold” (* event divider *):= “both” (* once per interval *)

track := “track” track_keyword “,”

track_keyword := “by_src” (* track by src ip *):= “by_dst” (* track by dst ip *)

events := events “,” time

events := “count” count (* event count *)

time := “seconds” seconds (* event period *)

count := INTEGER (* >0 *)

seconds := INTEGER (* >0 *)

INTEGER :: [0-9]+

Description

The threshold clause controls the rate at which events are issued for this rule. The rate can be limited to a number of events per period (limit), divided by a number of events per period (threshold), or both which emits a single event per period after a number of event detections. Event counts and period are tracked by source IP (by_src) or destination IP (by_dst).

Final 60


Example

# at most 10 events per hour alert ip any any -> any any \

( threshold:type limit, \track by_src, \count 10, \seconds 3600; \

content:”foo”; \)

# emit 1 event for every 10 events per minutealert ip any any -> any any \

( threshold:type threshold, \track by_src, \count 10, \seconds 60; \


# at most 1 event after at least 5 events detected per 24 hoursalert ip any any -> any any \

( threshold:type both, \track by_dst, \count 5, \seconds 86400; \


4.2.53. tos

Syntax

tos := “tos” “:” tos_expr “;”

tos_expr := value (* positive match *):= “!” value (* negative match *)


INTEGER :: [0-9]+

Description

Matches packets based on the value of the TOS field in the IP protocol header.

Example

alert ip any any -> any any ( tos:16; )

Final 61


4.2.54. ttl

Syntax

ttl := “ttl” “:” expr “;”

expr := relation value (* relation test *):= value “-” value (* range test *)

relation := “<” (* less than *):= “>” (* greater than *):= “!” (* not equal *):= “=” (* equal *):= ”<=” (* less than or equal *):= ”>=” (* greater than or equal *)


INTEGER :: [0-9]+

Description

Matches packets based on the Time To Live (TTL) field in the IP protocol header. This option can help detect “traceroute” attempts.

Example

# Match packets for which the TTL value is exactly 16.alert ip any any -> any any ( ttl:16; )

# Match packets with TTL values of 16 to 23 inclusive.

alert ip any any -> any any ( ttl:16-23; )

# Match packets with TTL values less than or equal to 100.alert ip any any -> any any ( ttl:<=100; )alert ip any any -> any any ( ttl:-100; )

# Match packets with TTL values greater than or equal to 100.alert ip any any -> any any ( ttl:100-; )

Final 62


4.2.55. uricontent

Syntax

uricontent := “uricontent” “:” search_expr “;”

search_expr := CONTENT_STRING:= “!” CONTENT_STRING

CONTENT_STRING :: “(\|[0-9a-fA-F ]+\|)|(\\[“\\:;|])|[^”\\:;|])+”

Description

The uricontent clause performs a content match on normalized HTTP URI data andis shorthand for a combination of content and http_uri clauses. Please refer to those options for additional information. This clause may be modified by depth, offset, distance, within and nocase clauses.

Example

alert tcp any any - > any any ( uricontent:”yahoo.com”; nocase; )

4.2.56. urilen

Syntax

urilen := “urilen” “:” expr “;”

expr := comparison (* check raw URI length *):= comparison “,” uri_type (* check URI length *)

comparison := value (* urilen equal to value *):= “<” value (* urilen < value *):= “>” value (* urilen > value *):= low “<>” high (* low < urilen < high *)

uri_type := “norm” (* normalized URI length *):= “raw” (* raw URI length *)

value := INTEGER (* 0 < value <= 2**32-1 *)

low := INTEGER (* 0 < low < high *)

high := INTEGER (* low < high <= 2**32-1 *)

Description

The urilen clause is used to match HTTP request URI length values. Values that are exactly equal, less than, greater than, or in between can be specified. Additionally, either the normalized or raw buffer lengths can be specified. If the buffer is not specified, the rule will evaluate against the raw buffer.

Final 63


Example

# Match a URI with a raw length of 10.alert tcp any any -> any any ( urilen:10; )

# Match a URI with a normalized length less than 10.alert tcp any any -> any any ( urilen:<10,norm; )

# Match a URI with a raw length greater than 1000.alert tcp any any -> any any ( urilen:>1000,raw; )

# Match a URI with a normalized length greater than 5 and less than 10.alert tcp any any -> any any ( urilen:5<>10,norm; )

4.2.57. window

Syntax

window := “window” “:” expr “;”

expr := win (* test window equal to value *):= “!” win (* test window not equal to value *)

win := INTEGER

INTEGER :: [0-9]+

Description

Matches packets having a specific value in the window size field of the TCP packet header.

Example

alert tcp any any -> any any ( window:5792; )

4.2.58. within

Syntax

within := “within” “:” value “;”

value := INTEGER (* 0 < value < 65536 *)

INTEGER :: [0-9]+

Description

Modifies the preceding content search to require a match within the indicated value.No more than within octets will be examined.

Example

alert tcp any any -> any any ( content:”foo”; within:64; )

Final 64


5. Examples with Explanations

alert tcp any any -> any any (msg:”Saw a \”yahoo\””; content:”yahoo”; nocase; sid:1000;)

This rule seeks the (case-insensitive) word “yahoo” in the payload of any TCP connection present in the traffic. This rule does not offer any particular utility except to allow emphasizing the requirement that TCP and UDP rules require the content option and argument.

alert tcp any any -> any any (msg:”Invalid”; sid:1000;) alert tcp any any -> any any (msg:”SYN”; flags:S; sid:1001;)

These rules are invalid! OpenSignature discards these rules because they specify the TCP protocol but do not provide a content option and argument. It also producesan error event (Issue ID 5,900,001) to warn of the invalid rule.

alert ip any any -> any any (msg:”Fragbits”; fragbits:+MD; sid:1000;)

Since this rule uses protocol IP, rather than protocol TCP, it does not need to specify a content option and argument. This rule triggers based purely on the fragmentationbits in the IP header of the packet.

alert icmp any any -> any any (msg:”ICMP ID”; icmp_id:512; sid:1000;) alert icmp any any -> any any (msg:”ICMP Seq”; icmp_seq:256; sid:1001;)

Again, the content option and argument are not required, since these rules use protocol ICMP. The first triggers whenever OpenSignature encounters an ICMP packet with the ID header field containing value 512. The second detects ICMP packets with the Sequence Number field containing value 256.

alert ip any any -> any any (msg:”IP Packet!”; sid:1000;)

This rule produces an avalanche of events, one for every IP packet processed! Needless to say, while a valid rule, it should never be deployed to an active system. The torrent of events would strangle almost any system, except on a very quiet network.

Final 65


6. External References

PCRE: Perl-Compatible Regular Expressions

Wikipedia: Extended Backus-Naur Form (EBNF)

RFC4632: Classless Inter-domain Routing (CIDR)

Final 66

https://tools.ietf.org/html/rfc4632

https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form

http://www.pcre.org/


7. Revision History

Revision

Date Description of Changes

1 18 March 2016 Major revision.

2 06 July 2016 Correct improper names, add missing tls_server_name context.

© Copyright IBM Corporation 2005, 2016. All Rights Reserved.IBM and the IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. ADDME, Ahead of the threat, BlackICE, Internet Scanner, Proventia, RealSecure, SecurePartner, SecurityFusion, SiteProtector, System Scanner, Virtual Patch, X-Force and X-Press Update are trademarks or registered trademarks of Internet Security Systems, Inc. in the United States, other countries, or both. Internet Security Systems, Inc. is a wholly-owned subsidiary of International Business Machines Corporation.

Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation in theUnited States, other countries, or both.

Other company, product and service names may be trademarks or service marks of others.

References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates, or to all customers within any country in which IBM operates.

Final 67

signature author's guide

Documents