ACID: Searching and Specifying Criteria
ACID provides a query builder to construct arbitrarily complex queries into
the alert database.
- There are four sub-groups of criteria:
- Meta: sensor, alert group, signature, classification, detection time
- IP: any IP header field
- layer-4: any TCP / UDP/ ICMP header field
- Payload: any layer-4 payload
- All criteria among the four sub-groups: Meta, IP, layer-4, Payload are collectively
applied with the AND operator between them; that is to say, any matched alert must
contain all the specified criteria in all the four sub-groups.
- On Layer-4 criteria (TCP/UDP/ICMP)
- In order to specify an upper layer protocol, merely click on the appropriate
button in the IP criteria
- Only one upper layer protocol is used as criteria at any given time
1. BASICS
Fundamentally all search criteria consist of three key elements:
- Criteria Type: is either a combo box (e.g. source or destination IP address) or a
hard-coded text identifier (e.g. signature) which defines the particular alert element
which will be specified as a criteria element. When a criteria type is a combo box
there will be a blank default value surrounded by curly braces '{ <criteria> }'.
- Criteria: is either a text box (e.g. signature) or checkbox (e.g. TCP flags) which accepts
the value to be compared against for the query.
- Operator: defines the relationship between the criteria type and the specified criteria.
Specifying the operator is always done via a combo box. The following operators are
possible:
'=' : equal to
(e.g. TCP source port 'is equal to' 80 )
'!=' : not equal to
(e.g. TCP source port 'is not' 80 )
'<' : less than
(e.g. TCP source ports 'less than' to 80 = 0 .. 79 )
'<=' : less than or equal
(e.g. TCP source ports 'less than or equal' to 80 = 0 .. 80 )
'>' : greater than
(e.g. TCP source ports 'greater than' to 80 = 81 .. 65535 )
'>=' : greater than or equal
(e.g. TCP source ports 'greater than or equal' to 80 = 80 .. 65535 )
'exactly' : the specified criteria will be matched exactly as the entire contents
of the field. The search is case insensitive.
e.g. signature 'exactly' 'buffer overflow' = matches 'buffer overflow'
= matches 'BUFFER OVERFLOW'
= NOT 'IDS01-buffer overflow'
= NOT 'buffer overflow-Win'
'roughly' : the specified criteria will be matched as a substring in the
appropriate field. It is functionality equivalent to the SQL call
" LIKE '*<criteria>*'"
e.g. signature 'exactly' 'buffer overflow' = matches 'buffer overflow'
= matches 'BUFFER OVERFLOW'
= matches 'IDS01-buffer overflow'
= matches 'buffer overflow-Win'
= NOT 'buffer/heap overflow'
'is' : the specified criteria combination will be matched exactly to the field.
e.g. TCP flags 'is' ACK-SYN = matches only alerts with ACK-SYN set
'contains' : the matched criteria must contain the specified criteria combination
e.g. TCP flags 'contains' ACK-SYN = matches any flags with ACK-SYN set
= matches ACK-SYN-FIN
= matches URG-ACK-SYN-FIN
= (etc ... )
'has' : the field will contain the specified criteria substring. The search is
case insensitive. It is functionality equivalent to the SQL call
" LIKE '*<criteria>*'"
e.g. Payload 'has' 'Snort' = matches '*Snort*'
= matches '*SNORT'
= matches 'SnorT*'
'has NOT' : the field does not contain the specified criteria substring. The search
is case insensitive. It is functionality equivalent to the SQL call
"NOT LIKE '*<criteria>*'"
Not all criteria lend themselves to this rich set of operators. When the operator
combo box is not present, then equality ('=') is the implied relationship between the
'criteria type' and the specified 'criteria'.
All criteria to be used in a query must have these three parameters set at a minimum. If
any are left blank the criteria is considered empty and is ignored.
2. ADVANCED
In addition to merely specifying a criteria type and criteria, ACID allows for
complex queries. To facilitate these queries, two new classes of operators are necessary.
These new operators must be used any time more than one criteria is specified within a
given sub-group (e.g. need to match two IP addresses, or multiple ICMP field).
- logical: 'NOT', 'AND', 'OR' : specifies the relationship between separate criteria.
e.g. : Range of values : __ TCP_port > 6000 __ AND
__ TCP_port < 6010 __ __
This criteria specifies a TCP port range (6000,6010) -
X-Windows
Protocol Codes : __ ICMP_type = 8 __ OR
__ ICMP_type = 0 __ __
This criteria specifies all ICMP echo request (=8) or
reply (=0)
- precedence: '(', ')' : specify the precedence of operations and allow logical
grouping of criteria.
e.g. : Complex Range of values: INCORRECT
__ TCP_port > 6000 __ AND
__ TCP_port < 6010 __ AND
__ TCP_port = 53 __ __
This criteria specifies a TCP port range (6000,6010) -
X-Windows, and DNS. It will return NO results.
CORRECT
( TCP_port > 6000 __ AND
__ TCP_port < 6010 ) AND
__ TCP_port = 53 __ __
This criteria specifies a TCP port range (6000,6010) -
X-Windows, and DNS (=53). Using parentheses groups the
X-Windows criteria into on criteria which is then ANDed
with the DNS criteria.
3. SPECIFICS: Meta
- sensor
- alert group
- signature name
- classification
- detection time
Time expressions can be built to specify single units of time or ranges.
| (single day)
|
| __ = Feb 01 2001 __:__:__ __ __
|
| Finds all alerts that occurred on February 1, 2001
| (open ended range)
|
| __ >= Feb 01 2001 __:__:__ __ __
|
| Finds all alerts that occurred from February 1, 2001 to the present
| (open ended range with date and time)
|
| __ >= Feb 01 2001 16:00:__
|
| Finds all alerts that occurred after February 1, 2001 @ 16:00
| (closed range)
|
| __ >= Feb 02 2001 __:__:__ __ AND
| __ <= Feb 04 2001 __:__:__ __ __
|
| Finds all alerts that occurred between February 2 - 4, 2001
| (non-contiguous dates)
|
| __ = Feb 02 2001 __:__:__ __ OR
| __ = Feb 09 2001 __:__:__ __ __
|
| Finds all alerts that occurred either on February 2 or February 9, 2001
4. SPECIFICS: IP
- source and destination IP address
IP addresses are expressed in CIDR notation. The following are valid expressions
of addresses:
10.0.0.1 => 10.0.0.1
10.0.0.1/32 => 10.0.0.1
10.0.0.1/16 => 10.0.*.* (any address with a first octet of 10, and second of 0)
- type of service (TOS)
- time to live (TTL)
- ID
- offset
- checksum
- length
5. SPECIFICS: TCP
- source and destination ports
- flags
- sequence number
- acknowledgment number
- offset
- res
- window
- checksum
- urgent pointer
6. SPECIFICS: UDP
- source and destination ports
- length
- checksum
7. SPECIFICS: ICMP
- type
- code
- sequence number
- ID
- checksum
8. SPECIFICS: Payload
It is possible to search on the layer-4 payload of an alert. However, there are numerous
encoding schemes currently implemented in Snort. Not all of them lend themselves the
search-ability. See the Snort DB documentation for a complete discussion, but essentially only
hex and acsii logging allow the payload to be searched.
- 'Input Criteria Encoding Type': how will the entered criteria be encoded?
- ascii: case insensitive
- hex: two digit hex is expected. All spaces will be eliminated, and there is no
case sensitivity.
- 'Convert To': how should the specified criteria be converted in order to be used as
search criteria?
- ascii: case insensitive
- hex: two digit hex is expected. All spaces will be eliminated, and there is no
case sensitivity.
e.g. DB payload encoding: hex
Your criteria: ascii = 'snort'
'Input Criteria Encoding Type' = ascii, 'Convert To' = hex