Expression Engine
The expression engine is a powerful matching and filtering system used throughout Netify Agent to define network policies, network intelligence rules, and classification criteria. It enables network administrators and integrators to craft sophisticated rules that match flows based on dozens of attributes.
Two syntax modes are available for creating flow expressions: a compact syntax optimized for simple use cases, and a full-featured standard syntax for more advanced logic.
- Compact Syntax
- Streamlined syntax for matching applications, protocols, and categories using short tags and identifiers.
- Standard Syntax
- Full-featured syntax with comparison operators, booleans, regular expressions, and dozens of flow attributes.
Compact Syntax
Introduced in Netify 5.2, the compact syntax provides a streamlined way to define flow classification rules for common and straightforward use cases. Compact rules are especially useful when building quick classifications, prototyping policies, or implementing well-defined matching logic without the overhead of full rule definitions.
A key feature of the compact syntax is the ability to invert any flow criterion using the logical NOT operator ! . This makes it easy to exclude specific matches or define negative conditions without restructuring the rule.
Compact Example - Flow Actions
"social": {
"criteria": "ac:social-media",
"targets": [
"ctmark.low-priority"
]
}
Applications and Protocols
The ai prefix can be used for application matching and the pi prefix can be used for protocol matching.
- ai:facebook
- Facebook application short tag
- ai:netify.facebook
- Facebook application full tag
- ai:119
- Facebook application ID
- pi:5
- DNS protocol ID
Application and Protocol Categories
For categories, the ac prefix can be specified for application categories, and the pc prefix for protocol categories.
- ac:adult
- Adult application category tag
- ac:2
- Adult application category ID
- pc:database
- Database protocol category tag
- pc:2
- Database protocol category ID
Standard Syntax
The standard syntax provides the most flexible and expressive way to define flow classification rules in Netify. It supports full logical expressions that can evaluate a wide range of flow attributes, including application, protocol, IP and MAC addresses, ports, and category metadata.
Unlike the compact syntax, standard expressions are designed for more advanced use cases where precise control, compound conditions, or layered logic is required. This makes it the preferred approach for production policies, complex filtering, and fine-grained traffic classification.
Comparison Operators
- ==
- Equal to
- !=
- Not equal to
- >
- Greater than
- >=
- Greater than or equal to
- <
- Less than
- <=
- Less than or equal to
Boolean Operators
- !
- Not
- &&
- And
- and
- And
- ||
- Or
- or
- Or
Regular Expressions
Introduced in 5.2, string type attributes support regular expressions using the rx: prefix. For example, if you wanted to match on the detected_hostname property:
"criteria": "detected_hostname == 'rx:.*xxx';"
Precedence
Use parentheses to explicitly define evaluation order. By grouping expressions within round brackets ( ), you override default operator precedence.
"criteria": "(a || b) && c;"
Lists
Multiple expressions can be joined in an implicit OR statement by setting the criteria to an array.
"criteria": [
"application == 'youtube';",
"protocol_id == 20;",
"protocol == 'icmp';",
"category == 'adult';",
"application == 'netify.linkedin';"
]
Match All / Wildcard
The simplest form of criteria is match all flows, accomplished with the use of the asterisk (*). An interface filter and/or exemptions can still be used to filter out flows when using a wildcard for the flow criteria.
...
"criteria": "*"
"interface": "br0",
...
Configlets
Specifying the criteria as a folder pathname causes individual configlets within the folder to be parsed and used as the criteria.
"criteria": "${path_state_persistent}/nfa-priority.d"
In this case, we could drop in the following configlet to define individual games we might want to prioritize:
/etc/netifyd/nfa-priority.d/10-server-games.conf
app == 'netify.rockstar-games';
app == 'netify.epic-games';
app == 'netify.ea-games';
Intelligence Object
The Intel plugin enriches network flows with real-time classification, threat assessments, and custom policy indicators. In addition to local scoring, it can fire off events directly to the Netify Flow Actions plugin, allowing dynamic rules to take action (e.g., shaping, prioritizing, or blocking) based on the intelligence data received.
To learn how to configure the Intel plugin to forward events to Netify Flow Actions, refer to the Intel Plugin Setup Guide.
Suppose an Intel indicator is configured as follows to define individual games we might want to prioritize:
/etc/netifyd/netify-proc-intel.json
{
"indicators": {
<snip>...
"games": {
"indicator_driver": "category",
"enabled": true,
"score": 80,
"categories": [
12
],
"cache": {
"max_age": 86400,
"max_size": 500,
"filename": "${path_state_persistent}/intel-cache/games.dat",
"flow_keys": [
"host_server_name",
"dns_host_name"
]
},
"criteria": {
"description": "Games",
"flow_expr": "application_id == 0 and protocol_id != 5 and other_type == other_remote;",
"netify_events": [
"category_games",
"nfa_prioritize"
]
},
"data_feeds": [
"cloud_intel"
],
"sink_targets": [
"default-log",
"default-socket"
]
},
...</snip>
}
Intel Object Evaluation in the Expression Engine
When an event reaches the Netify Flow Actions plugin, the payload includes an intel array containing intelligence objects matched during analysis. Consider the following array element payload:
Intel Event Object Example
"intel": [
{
"category": "custom",
"criteria": {
"min_bytes": 0,
"min_score": 10,
"trigger_on_east_west": true,
"trigger_on_wan": true
},
"data_feed": "",
"event": "dpi_complete",
"indicator": "games",
"indicator_driver": "custom",
"score": 50
}
]
Variable Name Flattening & Substitution
The Expression Engine automatically exposes every top-level attribute of the Intel object, as well as any nested attributes inside the criteria block, as evaluate-able expression variables.
This matching works by prefixing the top-level intel object name and using an underscore (_) as a delimiter:
- Top-level attributes map directly using
intel_<attribute>(e.g.,categorybecomesintel_category). - Nested criteria attributes concatenate their parent key path with an underscore using
intel_criteria_<attribute>(e.g.,min_scoreinsidecriteriabecomesintel_criteria_min_score).
Based on this rule, the following dynamic keywords are automatically available in your expression scope:
intel_categoryintel_criteria_min_bytesintel_criteria_min_scoreintel_criteria_trigger_on_east_westintel_criteria_trigger_on_wanintel_data_feedintel_eventintel_indicatorintel_indicator_driverintel_score
You can immediately use these flattened keywords inside your Flow Actions expressions to evaluate conditions:
Expression Example
intel_indicator == "games" and intel_criteria_trigger_on_wan == true and intel_score >= 10
Criteria Reference
Data Types
The data types used in the expression engine are detailed below. The address attribute is a flexible format that supports IPs, CIDRs, MACs and address groups.
| Type | Description | Examples |
|---|---|---|
| address | IP, CIDR, MAC or address group | 192.168.1.10, 192.168.1.0/24, 00:1a:2b:3c:4d:5e, @iot |
| hex | A hexadecimal value | 0x0303, 770 |
| integer | A standard integer value | 1, 43343 |
| string | A regular string, quotes required | "spotify", "social-media" |
| mixed | An integer or string | 156, "spotify" |
| boolean | Boolean value | detection_complete, !ip_nat |
| constant | Defined expression constant | origin_local, other_multicast, tunnel_gtp |
Only strings and mixed types are enclosed in single quotes. The Netify Agent will return an error when initializing the Flow Actions plugin on any deviation.