This commit is contained in:
parent
42f5d38d9b
commit
c9d2d4b306
|
@ -73,9 +73,7 @@ You cannot use comparison operators to compare a variable, such as a field
|
|||
value, to another variable, even if those variables are modified using a
|
||||
<<eql-functions,function>>.
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
====
|
||||
*Example* +
|
||||
The following EQL query compares the `process.parent_name` field
|
||||
value to a static value, `foo`. This comparison is supported.
|
||||
|
||||
|
@ -95,7 +93,6 @@ and `process.name` fields to static values.
|
|||
----
|
||||
process where process.parent.name == "foo" and process.name == "foo"
|
||||
----
|
||||
====
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
@ -219,9 +216,7 @@ _rounds down_ any returned floating point numbers to the nearest integer.
|
|||
EQL queries in {es} should account for this rounding. To avoid rounding, convert
|
||||
either the dividend or divisor to a float.
|
||||
|
||||
[%collapsible]
|
||||
.**Example**
|
||||
=====
|
||||
*Example* +
|
||||
The `process.args_count` field is a <<number,`long`>> integer field containing a
|
||||
count of process arguments.
|
||||
|
||||
|
@ -248,7 +243,6 @@ The following EQL query changes the integer `4` to the equivalent float `4.0`.
|
|||
----
|
||||
process where ( 4.0 / process.args_count ) == 1
|
||||
----
|
||||
=====
|
||||
====
|
||||
|
||||
[discrete]
|
||||
|
@ -383,9 +377,7 @@ sequence
|
|||
...
|
||||
----
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
====
|
||||
*Example* +
|
||||
The following EQL sequence query matches this series of ordered events:
|
||||
|
||||
. Start with an event with:
|
||||
|
@ -402,7 +394,6 @@ sequence
|
|||
[ file where file.extension == "exe" ]
|
||||
[ process where true ]
|
||||
----
|
||||
====
|
||||
|
||||
[discrete]
|
||||
[[eql-with-maxspan-keywords]]
|
||||
|
@ -422,9 +413,7 @@ sequence with maxspan=30s
|
|||
...
|
||||
----
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
====
|
||||
*Example* +
|
||||
The following sequence query uses a `maxspan` value of `15m` (15 minutes).
|
||||
Events in a matching sequence must occur within 15 minutes of the first event's
|
||||
timestamp.
|
||||
|
@ -435,7 +424,6 @@ sequence with maxspan=15m
|
|||
[ file where file.extension == "exe" ]
|
||||
[ process where true ]
|
||||
----
|
||||
====
|
||||
|
||||
[discrete]
|
||||
[[eql-by-keyword]]
|
||||
|
@ -453,9 +441,7 @@ sequence by field_foo
|
|||
...
|
||||
----
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
====
|
||||
*Example* +
|
||||
The following sequence query uses the `by` keyword to constrain matching events
|
||||
to:
|
||||
|
||||
|
@ -480,7 +466,6 @@ sequence by user.name
|
|||
[ file where file.extension == "exe" ] by file.path
|
||||
[ process where true ] by process.path
|
||||
----
|
||||
====
|
||||
|
||||
You can combine the `sequence by` and `with maxspan` keywords to constrain a
|
||||
sequence by both field values and a timespan.
|
||||
|
@ -493,9 +478,7 @@ sequence by field_foo with maxspan=30s
|
|||
...
|
||||
----
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
====
|
||||
*Example* +
|
||||
The following sequence query uses the `sequence by` keyword and `with maxspan`
|
||||
keywords to match only a sequence of events that:
|
||||
|
||||
|
@ -508,7 +491,6 @@ sequence by user.name with maxspan=15m
|
|||
[ file where file.extension == "exe" ] by file.path
|
||||
[ process where true ] by process.path
|
||||
----
|
||||
====
|
||||
|
||||
[discrete]
|
||||
[[eql-until-keyword]]
|
||||
|
@ -563,9 +545,7 @@ a process terminates, its PID can be reused.
|
|||
You can search for a sequence of events with the same PID value using the `by`
|
||||
and `sequence by` keywords.
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
=====
|
||||
*Example* +
|
||||
The following EQL query uses the `sequence by` keyword to match a
|
||||
sequence of events that share the same `process.pid` value.
|
||||
|
||||
|
@ -575,16 +555,12 @@ sequence by process.pid
|
|||
[ process where event.type == "start" and process.name == "cmd.exe" ]
|
||||
[ process where file.extension == "exe" ]
|
||||
----
|
||||
=====
|
||||
|
||||
However, due to PID reuse, this can result in a matching sequence that
|
||||
contains events across unrelated processes. To prevent false positives, you can
|
||||
use the `until` keyword to end matching sequences before a process termination
|
||||
event.
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
=====
|
||||
The following EQL query uses the `until` keyword to end sequences before
|
||||
`process` events with an `event.type` of `stop`. These events indicate a process
|
||||
has been terminated.
|
||||
|
@ -596,8 +572,6 @@ sequence by process.pid
|
|||
[ process where file.extension == "exe" ]
|
||||
until [ process where event.type == "stop" ]
|
||||
----
|
||||
=====
|
||||
|
||||
====
|
||||
|
||||
[discrete]
|
||||
|
@ -616,9 +590,7 @@ often use functions to transform indexed data, you can speed up search by making
|
|||
these changes during indexing instead. However, that often means slower index
|
||||
speeds.
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
=====
|
||||
*Example* +
|
||||
An index contains the `file.path` field. `file.path` contains the full path to a
|
||||
file, including the file extension.
|
||||
|
||||
|
@ -649,7 +621,6 @@ calls:
|
|||
----
|
||||
file where file.extension in ("exe", "dll")
|
||||
----
|
||||
=====
|
||||
|
||||
We recommend testing and benchmarking any indexing changes before deploying them
|
||||
in production. See <<tune-for-indexing-speed>> and <<tune-for-search-speed>>.
|
||||
|
@ -670,9 +641,7 @@ Pipes are delimited using the pipe (`|`) character.
|
|||
event_category where condition | pipe
|
||||
----
|
||||
|
||||
.*Example*
|
||||
[%collapsible]
|
||||
====
|
||||
*Example* +
|
||||
The following EQL query uses the `tail` pipe to return only the 10 most recent
|
||||
events matching the query.
|
||||
|
||||
|
@ -681,7 +650,6 @@ events matching the query.
|
|||
authentication where agent.id == 4624
|
||||
| tail 10
|
||||
----
|
||||
====
|
||||
|
||||
You can pass the output of a pipe to another pipe. This lets you use multiple
|
||||
pipes with a single query.
|
||||
|
|
Loading…
Reference in New Issue