How do I Configure Event Query, Alert Rules & Suppression Filters?

Follow

Event Query, Alert Rules and Suppression filters have the same syntax.

Event Types

The following event types are supported (and can be searched for using event_type= "[VALUE]")

  • audit - process audit events  
  • file - file integrity monitoring events
  • host - events triggered from host logs
  • login - login events
  • cloudtrail - cloudtrail events

The following keys are supported 

Key Type Value Description Present in Event Types
event_type string one of the following values: audit, file, host, login, or cloudtrail all
exe string The executable in the event, e.g. exe=/bin/exe  audit, file (some)
pid integer Process Id  audit, file (some), host (some)
arguments string Arguments string (E.g., argv), e.g. "ls -al /my/path" audit, file (some)
src_ip string IP address string, e.g. "10.4.2.4" network
dst_ip string IP address string, e.g. "10.4.2.4" network
agent string agent name, e.g.  "my agent" all
cwd string current working directory.e.g "/my/blah/path" all
ppid integer parent process ID audit, file (some), host (some)
timestamp integer epoch timestamp in milliseconds all
domain string domain name string network, audit (some)
ip string IP address string alias (either src_ip or destination ip) e.g. 1.2.3.4 audit (some), network
src_port integer source port  network
dst_port integer dest port network
port integer port (alias for src_port or dst_port) network, audit (some)
protocol string network protocol string, "tcp", "icmp", "udp" network
group string user group, e.g. "wheel" audit, host (some), file (some)
user string user, e.g. "root" audit, host (some), file (some)
connection.addr string IP address string (either src_ip or dst_ip) e.g. 1.2.3.4 audit
connection.src_addr string Source IP address. Aliased by src_ip  
connection.port integer tcp or udp port connected to by a network process audit
connection.src._port integrer Source port. Aliased by src_port  
command string command or exe run by a user or process. similar to key=exe but does not require full path to the exe audit
type string type of syscall, e.g start, connect, accept, bind  
syscall string

syscall name, e.g. start, connect, accept, bind

 

sudoer string

Displays all sudo events for a user. e.g. sudoer = "sam"

 

Syscall Reference(https://filippo.io/linux-syscall-table/)

 

Supported Operators

- matches 'equals'

Example: exe = "/bin/ls"     

- matches 'greater than'

Example: pid > 0 

- matches 'less than'

Example: pid < 1000

>= - matches 'greater than or  equal'

Example: pid >= 1000

<= - matches 'less than or  equal'

Example: pid <= 1000    

like - match a substring contained within a value.  The blob * should not be used.

Example:   arguments like "bob"   <- will match any arguments like *bob*, e.g. arguments = "ls bobcat"

and - boolean operator that joins two filters in an 'and' expression

Example:   arguments like "bob" and exe = "/bin/ls"     

or - boolean operator that joins two filters in an 'or' expression

Example:   arguments like "bob" or exe = "/bin/ls"   

starts_with - match a substring contained within a value. This should be used with an IP range in lieu of a wildcard * or CIDR notation

Example: ip starts_with "10.13." which is equal to 10.13.* or 10.13.0.0/16. Note: the trailing . is needed because without this "10.13" would also match 10.13x. 

Other Notes

  • Parenthesis can be used to group expressions, e.g. (arguments like "bob" and pid > 0) or exe = "/bin/ls" 

 

Alert Rules and Substitution Parameters

 

When you write the alert titles, you can use substitutions for fields in the events by putting them in double parenthesis "". For example, {{user}} would be replaced by the name of the user in the alert title.  

Those fields need to be aggregated (on the more options page on rules) for the substitutions to work.

Please not that, depending on the type of the event, we support some fields to aggregate. For login failures, we dont support aggregations yet, so you cannot do a on the alert title.

 

 

 

 

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments

8 comments
  • could you give an example using the "in" operator?

  • Kesten, We do not support "in" operator yet.  It is on the short term (next quarter) roadmap 

  • I must be reading this wrong. Is it really the case that event name is NOT a supported key for filters? So, for alert:

    CloudTrail Activity (Delete API Call): {{eventName}} by {{user}}

    You can't suppress based on eventName? Please tell me I'm missing something.

  • JB, you can suppress based on eventName for cloudtrail events.

  • Ok, thanks. It isn't noted above with the other valid keys, and doesn't work as expected when I try to apply it. At the very least, it looks like it doesn't support the same "like" syntax as other keys.

    I'll gather details and open a support ticket.

  • are there plans to be able to formulate rules based on tags?

  • Larry, yes in the pipe .

  • Still running into the same issues as a year ago - the "like" syntax does not seem to work _at all_. I can use a filter with 'arguments = "blah blah" ' and it works, but even changing the syntax to 'arguments like "blah blah"' causes it to fail. Cannot get "like" to return success for any filter, ever, at least in the arguments field. Is anyone having success with this? If so, I would greatly appreciate an example, as I suspect there's an element to the syntax that I'm missing.

Please sign in to leave a comment.