Rule templates

A rule template is a named set of rules you can copy into your global rules or into one machine in a single step. This page covers the Templates page, the ready-made templates EyalSec provides for common kinds of organization, creating your own, and applying or saving templates.

What a template is

A template is a named, saved list of rules. Applying it copies its rules into a scope, either your global rules or one machine's rules, where they become ordinary rules that you can edit, switch off or delete like any other. Templates hold rules only, not taint source settings.

Templates are shared by all your products: a rule carries no product, so one template works on any Filters page and any machine.

The Templates page

Open Templates in the sidebar. The page has two lists: EyalSec templates, a set EyalSec publishes for every account, and below it My templates, the ones you created. Each template is a card showing its name, the product it was written for (on the ready-made templates), how many rules it holds and its description, with buttons for what you can do with it.

If a template contains Raise rules and Raise is not enabled for your account, its card says so before you apply it, because those rules will be skipped.

When a list is empty it shows No templates yet.

EyalSec templates

EyalSec templates are ready-made rule sets that EyalSec maintains and every account can see. You can view and apply them, but not edit or delete them.

To adapt one, apply it and then change the copied rules, or apply it and use Save as template… to keep your version under your own name.

A template written for one product's events is tagged with that product, for example es-python. The Apply template… list on the other product's Filters page, or in a machine's Configure window for the other product, leaves it out, since its rules would match nothing there.

Ready-made templates for es-python

Every account starts with five ready-made es-python templates, one per common kind of organization, so you can pick the events that fit your company instead of working out every rule yourself. Pick the one closest to how you run your software, apply it, and adjust the copied rules from there.

What they have in common:

• They never narrow your list to a fixed set. Apart from the Raise rules in Block critical attacks, every rule is Hide (UI) or Don't send (drop) and names only what it removes. A new kind of finding still appears, whichever template you applied.
• They keep the serious findings in view. None of them hides commands, database queries, code evaluation, server-side templates, unsafe deserialization, outgoing requests to attacker-chosen addresses (SSRF), path traversal or leaked secrets, whatever source the data came from. The only exception is a rule that hides a whole source, such as env, which hides everything from that source.
• Their patterns name exact es-python event names, such as ^os (stat|lstat)$, so they do not touch es-chromium events.
• Applying adds rules and never removes any. If your account still has the two starting rules (Don't send re and write), they keep dropping every event whose name contains those letters. Review them when you adopt a template: re also matches names such as secret disclosure and foreign code.
• They are ordinary templates: apply one twice and nothing is added the second time, and you can apply more than one.

Web application (es-python)

For a web service or API (Django, Flask, FastAPI and similar), where the attacker is whoever sends a request. Data the service's own operators control, and housekeeping a request cannot exploit, is hidden; everything a request can reach stays visible, including what the service writes back to the network.

• Hide, source env, every event: values from the service's own environment variables.
• Hide, source argv, every event: its own command line.
• Hide, source stdin, every event: standard input, which a web service does not read requests from.
• Hide ^os (stat|lstat|access|listdir|scandir|readlink|getxattr|chdir)$: file lookups that read no contents. Opening a file whose path a request chose is still reported, as io open or path traversal.
• Hide writes to local files, pipes and the terminal (io ... write, os write, mmap write and similar). A write whose destination is a network connection, such as a response, is still shown, and so is log forging.
• Hide ^(ssl wrap_socket|socket (getaddrinfo|getnameinfo|gethostbyname|gethostbyname_ex))$: DNS lookups and TLS setup. A request-chosen destination is still reported as ssrf or socket connect.

Data and ML pipeline (es-python)

For batch jobs, ETL, notebooks and model training or serving that read datasets, model files and downloads. The attacker is whoever controls those inputs, so unsafe loading of data and model files, code evaluation, archive and file path handling, and commands and queries built from data stay visible.

• Hide, source env and source argv, every event: job settings your scheduler passes.
• Hide the regular expression events (re match, re search and the rest) and string formatting (% format, format): pipelines run these over every record.
• Hide file lookups, writes to local files, and DNS and TLS setup, as in Web application.
• Hide outgoing traffic: socket send, socket sendall, socket sendto, socket sendmsg and writes to a network connection, which is how a pipeline talks to its storage.
• Hide xss mark_safe and header injection, findings about a web page a pipeline does not serve.

CI, build and automation (es-python)

For build scripts, CI jobs, deployment and infrastructure automation. Here branch names, commit messages, environment variables and checked-out files can all carry an attacker's input, so nothing is hidden by source: commands, code loading, unsafe configuration loading, file paths and leaked secrets stay visible from every source.

• Hide the regular expression events and string formatting.
• Hide file lookups and file changes (os mkdir, os rename, os remove, os chmod, os symlink and the rest), which builds do all day.
• Hide writes to local files and logs. Secrets written to a log are still reported as credential logging or secret disclosure.
• Hide DNS and TLS setup, and the web page findings xss mark_safe and header injection.

Low noise (es-python)

For internal tools or a first rollout, when you want the findings most likely to matter and little else. It is the only template that changes what machines send: four Don't send (drop) rules stop the lowest-value events at the machine, so they are never stored and never count toward your event quota. They cannot be recovered later; switch the rules off to start receiving those events again.

• Don't send the regular expression events, string formatting, file lookups, and DNS and TLS setup.
• Hide, source env, argv and stdin, every event.
• Hide file changes, writes to local files, outgoing traffic, plain XML parsing (xml parse), and log and error messages (log forging, error disclosure).

Commands, queries, code, templates, deserialization, file paths and secrets stay visible.

Block critical attacks (es-python)

For teams that want es-python to stop the most dangerous attacks, not only report them. It holds four Raise (machine) rules, each limited to data that came from the network (source socket). When one matches, es-python stops the operation with a RuntimeError instead of running it, and the event is still recorded. It hides nothing.

• Raise ^(os system|subprocess shell|shell injection|command injection)$: a shell command.
• Raise ^(eval|exec)( \(untrusted code\))?$: eval or exec of network data.
• Raise ^ssti (jinja2|mako|django|tornado)$: a server-side template built from network data.
• Raise ^(yaml unsafe load|unsafe deserialization)$: unsafe YAML loading or object deserialization.

It deliberately leaves out operations that correct programs perform on network data every day: compile (which safe parsers such as ast.literal_eval use), pickle loads (which multiprocessing uses for its own messages) and running a program with a list of arguments (subprocess exec).

• Raise must be enabled for your account (see the Raise gate). Without it, every rule is skipped and applying adds nothing.
• Once any Raise rule applies to a machine, the --raise flag is ignored there.
• Try it on a test machine first: a blocked operation is an error in your program.

Create, edit and delete your own

Press + New template under My templates to open an empty editor. Give the template a Name (required, up to 128 characters) and, if you like, a Description (up to 512 characters). Press + Add rule once per rule, fill in each row, then press Save. Cancel closes the editor without saving.

Each row has the same fields as a rule in the rules table: Source, Event (regex), Mode and Sanitize. Press × to remove a row. There is no On column: a rule copied from a template is always added switched on.

• Edit on one of your templates opens the same editor, filled in. Save replaces its contents.
• Delete removes the template after you confirm. Rules you already applied from it are not affected.
• A pattern that is not a valid regular expression is outlined in red, and the template is not saved until you fix it.
• Template names must be unique among your templates. You can keep up to 50 templates, each with up to 200 rules.

Apply a template

Applying a template copies its rules into a scope: your global rules, or one machine's rules. Rules the scope already has are skipped, so applying the same template twice adds nothing the second time. Afterwards a message says how many rules were added and how many were skipped, and why.

There are two places to apply one:

• On the Templates page, Apply to my filters copies the rules into your global rules, which apply to every machine.
• Above a rules table, the Apply template… list copies the chosen template into that table's scope: the global rules on a Filters page, or one machine in its Configure window. The list groups EyalSec templates and My templates, and shows each template's rule count.

What gets skipped:

Before applying a template that contains a risky Don't send rule, the page asks you to confirm: one with an empty pattern drops every event from the scope, and one narrowed by Sanitize drops events that can never be recovered. See Don't send (drop).

Save a scope's rules as a template

Save as template…, above any rules table, saves the rules currently in that table as a new template of your own. You are asked for a name; the new template then appears under My templates on the Templates page.

Every rule in the table is saved, including rules that are switched off. It is a quick way to copy one machine's rules to another: save them from the first machine's Configure window, then apply the template in the second machine's.