Presenting Axiom Border

The rest of this section explains how to operate the probe. This part explains what it is and why it behaves the way it does — the seven ideas that, once you have them, make every screen in the console read the way it was meant to.

Read it in order the first time. Each page assumes the one before it.

Index

• What Axiom Border Is
• The Full Loop
• The Four Probes
• Passive and Active
• From Event to Alarm
• AI on the Probe
• Security Posture

Configuration

Axiom Border reads a single file, configuration.yaml, from the directory given by the AXIOM_CONFIG_DIR environment variable (default: config). An example file, configuration_example.yaml, is supplied alongside it — copy it rather than editing it in place, so you always keep an untouched reference.

cp config/configuration_example.yaml config/configuration.yaml

You will rarely edit the file by hand: the console’s Configuration view and the REST API write this same file — see Changing the configuration below.

sudo systemctl restart axiom-border

Changing the configuration

Three paths write the same file. The web console is the recommended one: it edits the settings a running deployment actually tunes, validates them before writing, and on a managed deployment restarts the service for you. The REST API covers automation and driving a probe without shell access. Editing the file over a shell always works — it is just the least guarded of the three.

​

Web console REST API

Open Configuration in the side menu. The view edits configuration.yaml itself, one group of settings per tab:

Each field is labelled in plain language rather than by its YAML key — nmap: period for schedule, vulnScan: depth for level — and the reference further down this page maps them to the keys they write. The two notices at the top are permanent, not the result of saving: they are there to tell you before you edit that nothing applies until the service restarts, and that the file holds credentials which are preserved for you.

Tab	What it edits
Automatic scans	The securityProbes switches and intervals: enable and schedule for nmap, vulnScan and snmp; the vulnerability scan’s level, severity and OT switches; the sniffing block, including where the probe reads its catalogues from
OpenGate	The whole opengate block — connection, collect and provision
MQTT	The whole mqtt block — the embedded broker with its WebSocket and TLS listeners, the internal publisher and the operations client

Everything else — logger, login, influxdb, apiPort, pagination and the per-probe details not listed above, scan targets included — is changed through the API or the file.

Network status has a shortcut straight here: its Automatic scans action opens this view on the first tab, which is where you land when a scheduled scan looks stale or too frequent.

The forms are a window onto the file, not a copy of it. Saving rewrites the whole file but preserves everything the forms do not manage: comments, credentials, and every key outside the three tabs. Leaving a field blank removes its key from the file, returning that setting to its unset behaviour. Durations, ports and cron expressions are checked as you edit, and Save stays disabled while any field holds an invalid value — an invalid document never reaches the probe.

What happens after Save depends on the deployment:

• On a managed deployment, the console asks the deployment manager (Keystone) to restart the service and waits until it reports healthy again — when the green confirmation appears, the change is already live. The console is unresponsive for the few seconds the restart takes.
• On a plain systemd installation, the file is written and an amber banner stays on screen until you restart the service yourself: sudo systemctl restart axiom-border.
• If the automatic restart fails, the write has still succeeded. Restart by hand — keystonectl restart axiom-border, or sudo systemctl restart axiom-border — and the saved configuration applies.

Changing apiPort or the login credential raises an explicit lockout warning: the file is written anyway, so before restarting make sure you can reach the new port or know the new password.

GET /config returns the current YAML and PUT /config replaces it. This exists so a probe can be configured for a customer environment without shell access to the host.

# 1. Authenticate
curl -X POST http://localhost:8083/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"<user>","password":"<your-password>"}'

# 2. Download the current file as a starting template (authenticated — it contains secrets)
curl -H "Authorization: Bearer <jwt-token>" \
  http://localhost:8083/config -o configuration.yaml

# 3. Edit it, then upload the COMPLETE file
curl -X PUT http://localhost:8083/config \
  -H "Authorization: Bearer <jwt-token>" \
  -H "Content-Type: application/x-yaml" \
  --data-binary @configuration.yaml

# 4. Apply
sudo systemctl restart axiom-border

The PUT response reports what happened:

{
  "restartRequired": true,
  "message": "configuration written; restart axiom-border to apply",
  "backup": "/opt/axiom-border/config/configuration.yaml.bak",
  "warnings": ["apiPort changes 8083 -> 9083 (may affect API access after restart)"]
}

Field	Meaning
restartRequired	Always true — configuration only takes effect at startup
message	Confirmation text
backup	Path of the previous file’s backup. Omitted when there was no previous file
warnings	Present only when non-empty. Raised when apiPort or the login credentials change, because either can lock you out

Console and API end in the same validated write, with three guarantees:

• Validation before writing. The document is validated exactly as at startup and checked for the six mandatory fields. Invalid YAML or a missing field returns HTTP 400 and nothing is written.
• Atomic replacement. The file is written to a temporary file in the same directory and renamed.
• Backup of the previous file, forced to 0600 because it contains secrets.

Where the file lives

Overriding any field with an environment variable

Every key can be overridden from the environment by upper-casing it and replacing dots with underscores. A .env file in the working directory is also loaded.

This is the recommended way to handle secrets: keep the tokens and passwords out of the YAML file entirely and inject them through the environment or your secret manager.

Required fields

Only six fields are validated as mandatory. If any is missing, the configuration is rejected:

login.user · login.pass · influxdb.url · influxdb.token · influxdb.org · apiPort

Everything else is optional and has a documented default.

logger

Backend logging, to console and to size-rotated files.

login

The single credential that protects the whole API except /auth/login.

Generate the digest before writing it:

echo -n "yourPassword" | sha256sum

At login, the probe hashes the submitted password and compares it against this value.

influxdb

Connection to the metrics database (InfluxDB 2.x) that stores metrics, audit records, scan results and alarms.

Default bucket set: network_bucket, ssh_bucket, metrics_bucket, usb_bucket, eg_alarms, audit_logs, networktraffic, availability, scanmetrics. The four per-channel event buckets are populated by the oda-lite collector, the rest by the probe itself — see Metrics ingestion.

The probe starts even when the metrics database is unreachable, and every feature that depends on it is inoperative until it recovers. This is deliberate for edge deployments where the database may be a separate node that boots later.

alerts and audit

Top-level keys

pagination

Controls the two read modes over the metrics database. Every field has a default, so the block can be omitted entirely.

trainerDetails

HTTP client settings for the AI container. Only relevant on Linux with a container engine available — see AI capabilities.

Three sub-blocks — metrics, healthCheck and predict — share the same four fields. The {port} literal in each URL is substituted at runtime with the port of the corresponding AI agent.

securityProbes

Security probes run two ways: automatically on an interval (schedule), and manually from the API or UI. Results are stored in local state and in the metrics database — scanmetrics for aggregates, availability for up/down.

securityProbes.nmap

Host discovery, port scanning and optional fingerprinting. Requires the nmap binary on PATH.

securityProbes.vulnScan

Template-based vulnerability scanning, including the embedded OT/ICS suite. The scan engine ships inside the product — there is no scanner binary to install.

level to tag mapping:

Templates directory resolution order: the templatesDir field of the scan request, then securityProbes.vulnScan.templatesDir, then defaultTemplatesDir, then a vulnscan-templates directory next to the product binary. Relative paths resolve against the working directory.

allowTemplateUpdates behaviour:

• true (default, including when the key is absent): best-effort refresh to the latest template release. Being offline or having GitHub blocked does not abort the scan — local templates are kept. An empty directory triggers a full download.
• false: strict offline kill-switch. The network is never touched, even when the directory is empty. If nothing is on disk the scan fails with a clear error.

allowTemplateBundleUpload is a different question, which is why it is a different key. allowTemplateUpdates asks may this process reach the network; this one asks may an authenticated operator replace the template set. The deployed recipe sets the first to false — correctly, an OT segment has no route out — so reusing it for uploads would have left the offline update path disabled on every real deployment, which is the one scenario the product exists for. Set this to false to freeze the templates at whatever the deployment installed; that is a posture, not the same decision as closing egress. See Offline maintenance.

allowIntrusive governs the write/control layer of the OT suite over both REST and MQTT. A request asking for intrusive mode while this is false is rejected, and the execution ends as failed with an explicit message. The scheduled probe is never intrusive regardless of this flag.

enableOT adds the read-only ot tag to the scheduled sweep even when level would not include it. It never enables the intrusive layer. Some older PLCs are fragile in the face of unexpected connections; enable it only if the OT network tolerates periodic probing.

Recommended steady state for a probe on an industrial segment:

securityProbes:
  vulnScan:
    enabled: true
    level: "medio"
    enableOT: true            # continuous read-only OT visibility
    allowIntrusive: false     # write layer bolted shut
    allowTemplateUpdates: false   # air-gapped: never reach for the network
    defaultTemplatesDir: "/opt/axiom-border/vulnscan-templates"

securityProbes.snmp

With neither oids nor walkRoot set there is nothing for the probe to do.

securityProbes.sniffing

Continuous traffic capture with periodic persistence to the networktraffic bucket.

Interface naming is platform-specific and is the most common source of a probe that captures nothing:

On Windows, the friendly name (Ethernet, Wi-Fi) does not work. Discover the NPF path with nmap --iflist and read the WINDEVICE column.

opengate

Optional cloud integration: inventory reporting (collect) and provisioning (provision). The whole section is inert when enabled: false.

opengate.collect

opengate.provision

mqtt

Three independent blocks: broker is the MQTT broker embedded in the product, client is the internal publisher of executions and alarms, and ops is the client that listens for OpenGate operations and answers them.

mqtt.broker

mqtt.client

Auto-reconnect is always on, retrying every 5 seconds, with a 10 second initial connection timeout. Neither is configurable.

mqtt.ops

If broker, topicSubscribe or topicPublish is empty, the operations module does not start.

Metrics ingestion and audit

Axiom Border’s data comes from two origins. The first one the probe captures by itself: the traffic it sniffs and the scheduled scans it runs against the network around it, with no cooperation from the equipment it watches. The second one is reported to it: every monitored machine runs an oda-lite agent that watches the machine from the inside and sends what it sees.

flowchart TB
    NET["The network around<br>the probe"]:::ext
    MACH["The monitored machines<br><i>an oda-lite agent on each</i>"]:::ext
    NET -->|"sniffing and<br>scheduled scans"| P["<b>Axiom Border</b>"]
    MACH -->|"SSH · USB · interface<br>· health events"| P
    P --> ST[("Metrics store<br><i>history and exports</i>")]
    P --> LP["Live pipeline<br><i>rules · alarms · audit</i>"]
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

Whatever the origin, the data ends in the same two places: the metrics store, which keeps the history behind queries and exports, and the live pipeline, where rules are evaluated, alarms are raised and the audit trail is written. This page follows that flow — the two origins first, then the pipeline, then how to read everything back.

What the probe captures by itself

The network-facing half needs nothing installed on the monitored equipment:

• Traffic capture — continuous sniffing of the configured interfaces, persisted periodically to the networktraffic bucket. Configured under securityProbes.sniffing.
• Scheduled assessments — the discovery, vulnerability and SNMP probes run on their configured intervals, keep the asset inventory current, and record per-scan aggregates (scanmetrics) and host up/down state (availability).

Both are documented in Security assessment. What matters on this page is that their results are data like any other: they land in the store, their executions are audited, and the audit log’s agent filter accepts the probe names (network, vulns, snmp, sniff) alongside the agent channels.

What the agents report

The host-facing half is delivered by oda-lite, a lightweight monitoring agent that ships alongside Axiom Border as a separate component with its own release cycle — the version you have is the one your package includes. It is the whole of the monitoring deployment role: a machine with that role runs only the agent, reporting to a central probe. The probe’s own machine runs one too, so the central host is watched exactly like every other node.

An agent watches four things, and each maps to a channel — the “Guards” of the console views:

Those four names are what the API calls {agentType}: they appear in the read paths (/recent/{agentType}), in the audit log’s agent filter, and as the group routing tag on every event.

flowchart TB
    AG["oda-lite agents<br>on each machine"]:::ext
    OTH["Other reporters<br><i>optional</i>"]:::ext
    AG -->|":9090/agents<br>line protocol"| COL["oda-lite on the probe host<br><i>central profile</i>"]
    OTH -->|":9091/metrics<br>JSON"| COL
    COL -->|"one bucket<br>per channel"| ST[("Metrics store")]
    COL -->|"POST /telegraf"| LP["Live pipeline<br>rules · alarms · audit"]
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

On the probe host, oda-lite runs in its central profile: besides watching its own host, it listens for everyone else on two ports —

Everything it receives — its own guards’ events included — goes two ways at once: each channel is written to its bucket in the metrics store, and every event is forwarded to the probe’s live pipeline, so rules, alarms, audit and the recent feeds see it immediately.

Two operational handles worth knowing:

• The agent is a systemd service on every node: systemctl status oda-lite. Its configuration is generated by the installer at /etc/oda-lite/oda-lite.conf — this is also where the listener ports move if 9090 or 9091 collide with something else.
• Agents buffer briefly and flush every few seconds, so an event appears in the console with at most a few seconds of delay — instantly is the wrong expectation, but a minute is a problem.

Seeing what is reporting in

Supervisions in the console lists the channels the probe is receiving data from. Each card is one channel, with a status dot, the last event it delivered, and the nodes it is monitoring.

This is the first place to look when data is not arriving: a channel with no recent event means the agent has either stopped, or never reached the probe. In the capture above METRIC-Guard is in exactly that state — there is no data to display. All events opens the full history for that channel.

The same data, turned around — Hosts Status

Supervisions answers which channels are reporting. Hosts Status answers how is each machine doing, which is the same data indexed the other way: one block per node, a status dot per monitor, the last event each one delivered, and the alarms currently open against that node.

The value of this view is that a problem is visible two ways at once. In the capture above the METRIC-Guard dot is red on all three nodes, and the alarm table beside it reads Node stopped reporting — the missing telemetry and the alarm it raised, side by side. That is the same silence the Supervisions view shows as an empty channel, seen from the node’s point of view instead of the channel’s.

Use Supervisions when you are asking whether a monitor is working, and Hosts Status when you are asking whether a machine is healthy.

The live pipeline: rules, alarms and audit

Events reach the probe itself through a single door, POST /telegraf — the same endpoint the collector forwards into.

Payload format

The body is {"metrics": [...]} and every metric requires all four fields:

The group tag is the routing key:

Beyond group, the conventional tags are eventType, ip, port and user — these are what rules and queries filter on.

curl -sk -X POST https://192.168.1.10:8083/telegraf \
  -H 'Content-Type: application/json' \
  -d '{
    "metrics": [
      {
        "name": "<machine-id>",
        "timestamp": 1746535617,
        "tags": {
          "group": "SSH",
          "eventType": "conn",
          "ip": "192.168.1.80",
          "port": "56390",
          "user": "unknown"
        },
        "fields": { "authevent": 1 }
      },
      {
        "name": "<machine-id>",
        "timestamp": 1746535623,
        "tags": {
          "group": "SSH",
          "eventType": "login_attempt_fail",
          "ip": "192.168.1.80",
          "port": "56390",
          "user": "operator"
        },
        "fields": { "authevent": 1 }
      }
    ]
  }'

The response is 200 with an empty body, or 400 if the JSON does not parse.

Reading data back

Everything up to here is visible in the console. What follows is not: pushing data in and pulling data out are the two jobs the console does not cover, because they exist to feed something else — a dashboard, an export, an integration. This is the part of the product where the API is the right tool rather than a shortcut.

There are three ways to read, and choosing the right one is the difference between a responsive UI and a slow one.

Recent feeds — for live views

These answer in microseconds, serving the most recent events the probe already holds without running a historical query. Feed depth is capped by pagination.maxRecentEvents, default 1000.

curl -sk -X POST https://192.168.1.10:8083/recent/ssh \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{"limit": 50, "orderBy": "desc"}'

{
  "count": 50,
  "warming": false,
  "elements": [ { "_measurement": "<machine-id>", "_time": "2026-05-06T13:27:03.000Z", "eventType": "login_attempt_fail", "user": "operator", "authevent": 1 } ]
}

Optional request fields: limit, uuids to filter by node, and orderBy for presentation order. Note that orderBy only affects how the returned page is sorted — the feed always yields the most recent events, so asc does not page backwards through history.

The warming flag is true while the feed is still being seeded after a restart. Surface it in a UI as a loading state rather than presenting a partial feed as complete.

Three feeds exist: /recent/{agentType} for events, /recent/alarms for alarms, and /recent/auditlog for audit entries. The audit variant takes timeOrder instead of orderBy and adds eventsId and agent filters — the latter also accepting the probe names network, vulns, snmp and sniff.

There is no total or pages in the response. The client paginates locally over what it received.

Paginated ranges — for historical queries

curl -sk -X POST https://192.168.1.10:8083/datapagination/ssh \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{
        "from": "2026-08-01T00:00:00Z",
        "to": "2026-08-03T00:00:00Z",
        "page": 1,
        "pageSize": 100,
        "orderBy": "desc"
      }'

A range read is answered in one of two ways, and the response metadata tells you which one you got:

Narrow ranges answer with full random access. Wide ones switch to sequential reading, and nextCursor carries the position of the following page.

{
  "elements": [ "..." ],
  "meta": {
    "total": 3412, "pages": 35, "page": 1, "pageSize": 100,
    "randomAccess": true, "exact": true,
    "range": { "from": "2026-08-01T00:00:00Z", "to": "2026-08-03T00:00:00Z" }
  }
}

To continue a sequential read, send only the cursor field — no from, no to, no page.

Pagination limits are configurable — see Configuration.

Exports — for taking data elsewhere

Streaming CSV, which is the one to use:

curl -sk -X POST https://192.168.1.10:8083/data/ssh \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{
        "uuids": ["<machine-id>"],
        "orderby": "desc",
        "range": { "initTime": "2026-08-01T00:00:00Z", "finishTime": "2026-08-03T00:00:00Z" }
      }' -o export.csv

The range is mandatory here, and a range exceeding pagination.rangeExportMaxRows (default 500 000) is rejected with 400 asking you to narrow it. That guard is deliberate.

Parquet, which behaves differently:

curl -sk -X POST https://192.168.1.10:8083/parquet/ssh \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{"uuids": ["<machine-id>"]}'

Other read helpers

Aliases — making UUIDs readable

Nodes are identified by machine ID, which is unreadable. An alias maps one to a name, and every read endpoint accepts ?alias=true to perform the translation. The console displays aliases wherever it lists nodes, but creating them is an API operation:

curl -sk -X POST https://192.168.1.10:8083/alias \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{"alias": "plc-line-1", "uuid": "<machine-id>"}'

With ?alias=true, the uuids filter in a request body also accepts alias names, so a client can work entirely in readable names. Note that DELETE /alias takes the alias name, as {"name": "..."}, not the UUID.

Audit

Every significant action is audited to the audit_logs bucket. Two ways to read it:

# Live tail
curl -sk -X POST https://192.168.1.10:8083/recent/auditlog \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{"limit": 100, "timeOrder": "desc"}'

# Historical, filtered to vulnerability scans
curl -sk -X POST https://192.168.1.10:8083/auditlog \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{
        "from": "2026-08-01T00:00:00Z",
        "to": "2026-08-03T00:00:00Z",
        "agent": "vulns",
        "pageSize": 100
      }'

The agent filter accepts the four channel names and the four probe names. Filtering by vulns is how you answer “what was scanned, when, and by whom” — including the warning entry that every intrusive OT scan generates.

Storage layout

Where each kind of data ends up. The four channel buckets are written by the collector; everything else is written by the probe itself:

Buckets are created on first start if absent. Note that no retention policy is applied by default — configure retention in InfluxDB according to your disk budget, or the metrics buckets will grow without bound. An Influx bucket with no retention is a common cause of a probe slowly filling its disk.

Alarms and the rules engine

Axiom Border decides locally. A probe that only forwards data is useless the moment the uplink drops, so alarm evaluation runs on the device, against data it already holds, with no dependency on the platform.

There are two ways to express what should raise an alarm:

Checks cover most of what monitoring needs and need no code. Scripts exist for the cases checks cannot express.

Where you work with alarms

Alerts in the console is the operator’s view: the alarms currently raised, the history of what has been logged, and the Rules configuration button that opens the editor for the rules described below. An autoreload toggle keeps the list current while you watch an incident develop.

Each row names the alarm, the check type behind it, the node it came from, the agent, the severity and a description that includes when the condition was first seen. ACK acknowledges the selected alarm.

Two tabs sit above the table. Recent reads the live feed — the most recent alarms the probe already holds, answered immediately. Range queries a time window from history instead, which is what you want when reconstructing an incident after the fact:

Rules configuration opens the Alarm config screen, which is where both kinds of rule live — the declarative alarm rules in the upper table, and the JavaScript Expert System at the bottom with its own enable switch:

Everything on this page can be done from that screen or from the API, and both paths are shown together wherever they differ.

Checks — declarative rules

A check watches one event type from one agent over a time window, and raises an alarm when its condition holds.

flowchart TB
    EV["Event arrives"] --> MATCH{"Matches<br>a check?"}
    MATCH -->|no| DROP["Stored only"]
    MATCH -->|yes| TYPE{"Check type"}
    TYPE -->|count| CNT{"Count over<br>threshold?"}
    TYPE -->|deadmachine| SILENT{"Silent for<br>the window?"}
    CNT -->|no| WAIT["Keep counting"]
    CNT -->|yes| FIRE["Raise alarm"]
    SILENT -->|yes| FIRE
    FIRE --> COAL{"Alarm<br>already open?"}
    COAL -->|yes| INC["Increment count"]
    COAL -->|no| NEW["New alarm"]

The two check types

deadmachine is the one worth calling out: it alarms on absence, which is how you detect a node that stopped reporting rather than a node reporting something bad.

Creating a check

​

Web console REST API

From Alerts → Rules configuration, use New alarm rule. The wizard walks three steps — Rule config, Alarm config and Summary — and collects exactly the fields described above:

Rule type is the check type, Agent and event choose what to watch, Trigger sets the window and the count, and UUIDs selects the nodes. Only agents actually reporting in are offered, which is why a rule cannot be created before its agent has sent data.

curl -sk -X POST https://192.168.1.10:8083/checks \
  -H "Authorization: Bearer <jwt-token>" \
  -H 'Content-Type: application/json' \
  -d '{
        "checkName": "ssh-bruteforce",
        "agent": "ssh",
        "ctype": "count",
        "event": "login_attempt_fail",
        "freqs": "5m",
        "threshold": 10,
        "level": "critical",
        "alarmName": "SSH brute force attempt",
        "alarmDescription": "More than 10 failed SSH logins in 5 minutes",
        "uuids": ["<machine-id>"],
        "enable": true
      }'

Every field is required on create. freqs is a duration string — 30s, 5m, 1h. level is info, low, medium, high or critical. uuids lists the nodes the check applies to, and accepts alias names when the request carries ?alias=true.

A worked example: catching a node that went quiet

The most valuable check is usually the one that alarms on silence. In the wizard, choose dead machine as the rule type, pick the agent that reports the node’s health, set the window to something comfortably longer than its reporting interval — ten minutes against a one-minute heartbeat — and select the nodes it applies to.

There is no threshold to set: the condition is that nothing arrived. Give the alarm a name an operator will understand at three in the morning, such as Node stopped reporting.

Managing checks

The rules table on Alerts → Rules configuration lists every check, and each row carries its own edit and delete actions. Editing reopens the same wizard.

To pause a check without losing its definition, switch it off rather than deleting it.

Alarm coalescing

A brute-force attempt that trips a threshold every five minutes for an hour should be one alarm with a count, not twelve identical alarms. Axiom Border coalesces repeated firings of the same rule against the same node into a single open alarm:

The alarm stays open and accumulating until someone acknowledges it. Acknowledgement is what closes the coalescing window — the next occurrence after an acknowledgement opens a fresh alarm, so the operator gets a new signal rather than a silent increment on something they already dealt with.

Acknowledging

Select the alarm on the Alerts view and use ACK. It is marked as seen, with who acknowledged it and when.

If someone else got there first, the action is refused rather than applied twice — worth knowing when two operators are working the same incident.

Reading alarms

The two tabs above the table reach the same events by different routes:

Columns filter individually, and the autoreload control keeps the list current while you watch.

Each alarm carries its name and description, the check type behind it, the node and agent it came from, its severity, when it was raised, whether it has been acknowledged, and the coalescing trio of first seen, last seen and count.

Rule scripts

For logic that a declarative check cannot express, Axiom Border runs rule scripts written in JavaScript. They are evaluated on the device, server-side, on events you did not trigger.

In the console these are the Expert System, edited from Alerts → Rules configuration → Edit script. The editor opens on a working skeleton, so you can see the shape a script must have before writing one:

Note the Enable switch beside the editor on the Alarm config screen: a saved script does nothing until it is turned on.

How scripts are organised

A script is identified by name, and the name determines when it runs. Scripts named after an agent — ssh, iface, usb, metrics — run on events for that agent. Scripts named after a probe — network, vulns, snmp, sniff — run on that probe’s findings. A general-purpose rulesengine script runs over every ingested batch.

Every script has an enabled state, set with the ?enabled= query parameter when you upload it and reported by GET /scripts. A disabled script is stored but never invoked.

The script contract

A script must define a function called process, which receives the batch of metrics:

function process(metrics) {
  for (var i = 0; i < metrics.length; i++) {
    var metric = metrics[i];
    metric.SetT0();
    // your logic here
    metric.SetT1();
  }
}

SetT0() and SetT1() bracket your processing and are what populate the timing fields in the audit record. They are not required for the rule to work, but including them is the convention and it makes slow rules visible.

Available globals

Each metric exposes: GetTagByName(key), GetFieldByName(key), ExistsField(key), GetMetricName(), GetAliasName(), GetAgentType(), GetMonitoredEvents(), GetEventValues(), GetTime(), SetT0(), SetT1() and String().

A worked example, raising an alarm when a scan finds a risky port open:

var RISKY_PORTS = { 23: "telnet", 21: "ftp", 3389: "rdp", 445: "smb", 5900: "vnc" };

function process(metrics) {
  for (var i = 0; i < metrics.length; i++) {
    var m = metrics[i];
    m.SetT0();

    if (m.GetTagByName("kind") === "port" && m.GetFieldByName("portStatus") === "open") {
      var port = m.GetFieldByName("portNumber");
      if (RISKY_PORTS[port]) {
        newAlarm(m, "critical",
          "Risky service " + RISKY_PORTS[port] + " exposed on port " + port,
          "Risky port open", "port_discovery");
      }
    }

    m.SetT1();
  }
}

The tags and fields available per probe are documented in the header comment of each deployed script, so read the script with GET /scripts/{scriptname} before writing rules against it.

Saving and enabling a script

Everything happens in the Expert System editor on the Alarm config screen: write or paste the script, save it, and use the Enable switch beside it.

Scripts can also be managed through the API — /scripts lists them with their enabled state, and each one can be read, replaced or deleted by name. That is what an automated deployment would use; from a browser the editor is the shorter path.

gojaTimeout: "8s"

Scripts can call the AI model

A script can invoke inference against a deployed AI capability, using the predict endpoint configured under trainerDetails.predict. This is what connects anomaly detection to alarm generation: the model scores an event, and the script decides whether that score warrants an alarm.

Timeouts and retries for that call come from trainerDetails.predict — default 10 s, one retry. Note that the call is bounded by gojaTimeout as well, so a predict timeout longer than the script timeout cannot complete. Keep gojaTimeout comfortably above the predict timeout if your rules use inference.

See AI capabilities for deploying a model in the first place.

Security probe results reach the rules engine too

Security probe findings are evaluated by the rules engine and audited exactly like agent metrics. A scan finding can therefore raise an alarm the same way a metric can — a newly discovered host, a critical vulnerability, a port that opened when it should not have. See Security probes.

Choosing between a check and a script

Reach for a check when the condition is “this event, this many times, this window”. It is declarative, visible in the API, and cannot fail in interesting ways.

Reach for a script when you need to remember something between events, combine two signals, compute a value, or ask the model. The cost is that scripts are code: they need a timeout that works, they fail in ways checks do not, and they are harder to audit at a glance.

If a check can express it, use the check.

Where alarms go next

Locally, alarms land in eg_alarms and surface through the feeds above and in the web console.

If OpenGate integration is enabled, alarms and executions also publish over the embedded MQTT broker and are forwarded to the platform, which is how a fleet of probes becomes a single operational picture. See MQTT and OpenGate operations.

Security probes

Axiom Border assesses the network it sits on with four probes. They share one execution model, one audit trail and one accumulated view of results, so the findings of each one reinforce the others instead of living in separate reports.

Each runs two ways: automatically on a schedule you configure, and manually from the console when you want an answer now.

flowchart TB
    DISC["Network discovery<br><i>live hosts and ports</i>"]
    DISC --> VULN["Vulnerabilities"]
    DISC --> SNMP["SNMP identity"]
    PASS["Passive analysis"] --> INV
    VULN --> INV
    SNMP --> INV
    DISC --> INV[("Consolidated<br>inventory")]
    INV --> ALARM["Alarms and<br>audit trail"]

Network discovery establishes the baseline for the two probes that ask questions, and that ordering matters: a vulnerability scan with no explicit target scans every host in the baseline, so discovery must have run for it to have anything to do. Newly discovered hosts also trigger a vulnerability scan on their own, grouped together after a short delay, so new assets get assessed without waiting for the next scheduled sweep.

Passive analysis stands apart — it needs no baseline, because it is not asking anyone anything. See Passive and active for why the two must not be read as the same kind of result.

Network status — where all of it lands

The header names the last assessment that ran and how it finished, so you can tell at a glance whether what you are looking at is current. Three buttons launch and configure the probes:

Each host row carries its own actions — Ports, Vulnerabilities and SNMP — each opening that host’s detail and each able to re-scan just that host, so you can reassess one asset without sweeping the whole range.

Network discovery and port scanning

Scan network opens the launch dialog. Every option the probe supports is here, so there is no reason to drop to the API for a scan:

What discovery gives you per host

A host’s Ports panel lists what it is listening on, with the service the scan identified and when each port was first and last seen:

The first-seen and last-seen pair is what makes this more than a snapshot: a port with a recent first seen is new, and that is usually the thing worth acting on. The panel re-scans just this host, so you can confirm a change without sweeping the range again.

Scheduled discovery is configured under Configuration → Automatic scans, in the nmap block.

Vulnerability scanning

Two distinct halves. The generic half uses the bundled upstream template set. The OT/ICS half uses Axiom Border’s own suite of 57 industrial protocol checks, which travel inside the product and work with no internet access. Both are covered in Catalogs: vulnerabilities, OIDs, MIBs and more.

Open a host’s Vulnerabilities panel and use Re-scan IP address vulnerabilities:

Depth is the setting that matters most, and the dialog explains each option as you select it:

Selection is by check family rather than by folder, so it does not depend on how the template set is laid out on disk.

Severity toggles which findings are reported at all, and Intrusive mode (OT/ICS) is the switch that adds checks which write to the device rather than only reading it.

Reading a finding

Name says what was confirmed — Modbus/TCP Diagnostics Function Exposed Without Authentication — and Description explains how it was confirmed and why it matters. CVE is empty whenever the finding is an exposure rather than a published vulnerability, so Template ID is the stable way to refer to one.

Origin is the column to read first: probe means the request was sent and the target answered, while inferred means it was derived from the device’s identity with no traffic emitted — a lead to verify, not a demonstrated fact. Confidence qualifies it further, and where an inference has evidence behind it, the Evidence toggle in that column opens it.

Checks from the write/control layer are marked twice over: the name ends in [INTRUSIVE] and the description opens with INTRUSIVE / GATED.

Detected, and what is merely potential

The table is titled Detected vulnerabilities, and the word is doing real work. It holds what was confirmed by an active scan, plus inferences where the product was actually identified. What it does not hold is the surface attributable to a device known only down to its manufacturer — that would be hundreds of rows the probe cannot stand behind, burying the findings you can act on.

That surface is not discarded. It is summarised above the table, as a count with its severity breakdown and a recommendation to scan the host actively.

There is a cap on how many unconfirmed CVEs a single device lists individually before it switches to a summary — 30 by default. Version-confirmed findings are never summarised, however many there are. The cap is sniffing.passiveVulnRowLimit in Configuration; a negative value removes it and lists everything.

SNMP — interrogation and profiles

Open a host’s SNMP action to query it. The panel takes symbolic names as readily as numeric OIDs and carries a Standard OIDs helper that explains the common ones in plain language, so you do not need a MIB browser open beside you:

Results render as a table or as a tree, and the tree is the one to use after a walk. How names resolve to numbers and back is covered in Catalogs: vulnerabilities, OIDs, MIBs and more.

Profiles instead of credentials

Rather than supplying credentials with every query, store them once as a profile and bind it to the hosts it applies to. The console has a wizard for this, with predefined profiles to start from, reachable from the SNMP panel’s profile selector.

Supported versions are v1, v2c and v3. For v3 the console explains the three security levels as you choose between them — only authPriv both authenticates and encrypts, and it is the only one that hides what is being polled rather than merely proving who is asking.

Resolution order when a scan runs: the profile named in the request, then the profile bound to that host, then the configured default. A target that resolves to no profile is skipped, and the execution says so.

Passive analysis

The one probe you do not launch. It listens continuously on its capture interface and emits nothing, building an inventory indexed by MAC address alongside the address-indexed one the active probes fill.

Passive analysis on the Network status header opens what it has established:

Three tabs: the per-device Inventory with vendor, type, role and the confidence behind each, the LLDP neighbours it has overheard, and Findings such as the capture-point verdict, gateway identification and address conflicts.

The type and role columns are where the industrial coverage shows. The probe recognises thirteen industrial protocols carried over IP — Modbus, S7comm, OPC UA, DNP3, IEC-104, EtherNet/IP, BACnet, CODESYS, MELSEC, PTP, HART-IP, KNXnet/IP and FINS — and records which side is serving and which is asking. It also reads four protocols that travel directly over Ethernet with no IP layer at all: IEC 61850 GOOSE and Sampled Values, PTP/IEEE 1588, and PROFINET DCP. On a substation or production segment those are frequently the bulk of the traffic, and nothing that keys off addresses and ports can describe them. See Passive and active for the full picture, including which ports are vendor convention rather than registered and are therefore reported at lower confidence.

The neighbours tab is LLDP only. The probe sees and counts Cisco’s own discovery frames, but it does not derive neighbours from them — so a segment of Cisco equipment speaking CDP rather than LLDP produces traffic the probe accounts for and a neighbour table that stays empty. That is a limitation, not a fault to chase. The coverage note above the table states plainly what the figure leaves out — passive analysis only sees what talks, so a silent device is not counted.

Everything about it is configured under Configuration → Automatic scans, in the sniffing block: which interfaces to capture on, an optional capture filter, which observed addresses reach the host inventory, how often what it learns is persisted, and whether it infers vulnerabilities from identity.

The shared execution model

Every launch is asynchronous: the request is accepted, the work continues in the background, and the Network status header reports the state of the most recent run as it progresses. A run ends as finished or failed, and a run interrupted by a probe restart is moved to failed on start-up rather than being left in progress forever.

The merged result view

An individual execution tells you what one probe found. The Network status table tells you what is known about a host, merged across all four probes: address and hostname, MAC address, manufacturer and device type with their provenance, operating system, status, when it was first and last seen, then the per-probe contributions — ports from discovery, findings from vulnerability scanning, values from SNMP, and traffic counters from passive analysis.

The first-seen and last-updated pair is what turns the baseline into change detection: a host with a recent first-seen is new to the network.

This same merged view is available through the API for dashboards and integrations, at GET /security/results/last.

Feeding results into rules

Probe results reach the rules engine, so a finding can raise an alarm the same way a metric can — a new host appearing, a critical vulnerability, a port opening that should not be open. See Alarms and rules.

Index

• OT/ICS Vulnerability Scanning

What the probe knows before it is plugged in

A scanner is only as good as the data behind it, and the usual arrangement is to fetch that data on demand: a vulnerability feed pulled at scan time, a vendor lookup resolved against a web service, a MIB downloaded when an unknown OID turns up. Every one of those assumes a route to the internet.

Axiom Border carries all of it. Nothing is downloaded at run time — not before a scan, not during one, not to interpret a result afterwards. A probe in an air-gapped plant resolves manufacturers, names OIDs, and matches vulnerabilities with exactly the same coverage as one sitting in an office.

What ships, and where it comes from

Every figure above is what the probe reports about itself. None of it needs a network to be true.

Vulnerabilities — why those 20 vendors

The vendor list is not “who makes industrial equipment”. It is which vendors the probe can actually put a name and a version to from what it observes — a neighbour announcement, a MAC address block, or a device declaring itself. A vendor the probe cannot identify would contribute rows that could never match anything.

The last group is there on purpose, and it is not a category error. Neither vendor makes industrial equipment, but both turn up in plants regardless — the NAS somebody parked the historical data on, the router somebody plugged in. The probe identifies them by MAC address block like anything else and their firmware carries versions, which is the only criterion this list applies.

What is in there, by severity: 1,341 critical, 4,853 high, 4,316 medium, 215 low, and 2,549 not scored, spanning disclosures from 1999 to 2026.

The database is what turns an identity into a finding without emitting a packet, and how complete the identity is decides what the probe is allowed to say:

That last row is the one worth reading twice. A host identified only down to its manufacturer is not a clean host — it is one the probe could not narrow far enough to name a finding. Reporting it as an empty row would be the single most misleading thing an assessment tool can do, so it reports the size of what it cannot yet see instead.

Manufacturers — the registry and the floor beneath it

The installed IEEE registry turns a MAC address into a vendor name. It wins for the prefixes it carries; everything else keeps resolving against the table built into the product. See Passive and active for how that claim is presented with its evidence and its caveats.

OIDs and MIBs — the SNMP catalogue

An OID like .1.3.6.1.4.1.6574.2.1.1.5 means nothing on its own. Turning it into diskTemperature requires a MIB, and on an air-gapped probe you cannot look one up — so the catalogue ships with the product.

The modules are vendor-published MIBs, gathered from the manufacturers’ own documentation and public MIB collections, and installed as a single catalogue. It is treated as an external source of truth: it is not hand-edited, and it is refreshed as a whole rather than patched.

Vulnerability check templates

Two origins, and the pin is what holds the offline model together.

The generic templates come from the upstream project, pinned to a fixed release, and the engine’s own self-update is switched off. Both are load-bearing: an engine allowed to chase “latest” would try to download templates the first time it ran a scan, and a probe with no route out would simply fail there.

The OT/ICS suite is written in-house and lives inside the probe itself rather than in the templates directory. It is written out to disk each time a vulnerability scan runs, and anything left over from a previous version is removed at the same time.

Where the probe looks for them

All three locations are set from Configuration → Automatic scans, and the defaults are correct for a standard installation — you only touch these to point the probe at data you placed somewhere else.

Sniffing: passive vulnerabilities, on the same screen, is the switch that turns identity into findings after each observation window. With it on and no CVE database seeded, you still get identity — you just get no CVEs from it.

Working with OIDs from the console

Network status → the SNMP action on a host row opens the query panel. This is the normal way to interrogate a device, and it needs no knowledge of OID numbering at all:

• Version and Port set how to talk to the device.
• Add OID takes a symbolic name or a numeric OID. You can paste several at once, separated by commas, spaces or line breaks.
• Standard OIDs expands into the common ones grouped by purpose — System, Interfaces, Host resources — each explained in plain language rather than by number. sysDescr is described as vendor, model and firmware, all in one string; sysObjectID as the vendor’s identifier for the model — the usual fingerprint. Click one to add it.
• Manual OID / Retrieve OID switches between naming OIDs yourself and reading back what the probe already holds for that host.
• Results render as a Table or a Tree, and the tree is the one to use after a walk.

Credentials do not belong in this panel. Store them once as an SNMP profile — the console has a wizard for it, with predefined profiles to start from — and bind the profile to the host. See Security assessment.

How resolution works

Two directions matter, and they behave differently: symbols become OIDs before the request goes out, and OIDs get names again on the way back.

Inbound, when a query contains symbolic names, they are resolved before anything is sent on the wire: first a small built-in table of the universal system OIDs, then anything already numeric passes through untouched, then everything else is looked up in the vendor’s modules.

flowchart TB
    S["Requested name<br>sysDescr"] --> C1{"Built-in<br>system OID?"}
    C1 -->|"no"| C2{"Already<br>numeric?"}
    C2 -->|"no"| C3{"In the vendor's<br>modules?"}
    C3 -->|"no"| FAIL["Query fails<br>unresolved oids"]:::danger
    C1 -->|"yes"| OK["Numeric OID<br>sent on the wire"]
    C2 -->|"yes"| OK
    C3 -->|"yes"| OK
    classDef danger fill:#fff0ed,stroke:#ff664e,color:#101010

Outbound, every OID that comes back is put through four steps, first match winning: the built-in system OIDs; the vendor’s modules, trimming up to two trailing segments — which is how indexed OIDs such as ifDescr.3 resolve to ifDescr; the SNMPv2 module; and a set of generic modules by exact match. If nothing matches, the name comes back as unknown. The value is still returned — only the label is missing.

The vendor hint

Symbol resolution needs to know which vendor’s modules to search. Axiom Border works it out in order:

1. The MIB named in the query itself.
2. The default MIB from Configuration → Automatic scans → SNMP: default MIB.
3. Inferred from the host’s manufacturer, as already recorded in the inventory.

The third is the useful one, and it is why running discovery before SNMP pays off: the manufacturer already established for that host becomes the vendor hint automatically. Explicit rules exist for common vendors — Synology, Cisco, HP, Huawei, Juniper, D-Link — falling back to the first word of the manufacturer name.

The hint is only consulted when a query actually contains non-numeric symbols. All-numeric queries need no vendor at all.

Values in results

Each result entry carries the numeric OID, the resolved name (or unknown), the formatted value and a status. Values are formatted by type: numbers as numbers, IP addresses in dotted form, and byte strings as text when they are printable, otherwise as hexadecimal — so binary values are legible rather than mangled.

Browsing the MIB catalogue

Listing vendors, searching for a symbol and inspecting a module are not in the console — the catalogue browser is available through the API only. Day-to-day this rarely matters, because the Standard OIDs helper covers the common cases and the vendor hint resolves the rest automatically. Reach for these when you are working out what a specific vendor exposes.

# Vendors and their modules — inexpensive regardless of catalogue size
curl -sk https://192.168.1.10:8083/security/mibs \
  -H "Authorization: Bearer <jwt-token>"

# Search for a symbol. Always pass vendor when you can
curl -sk 'https://192.168.1.10:8083/security/mibs/search?q=diskTemp&vendor=synology&limit=50' \
  -H "Authorization: Bearer <jwt-token>"

# Inspect one module. Names are exact and case-sensitive
curl -sk https://192.168.1.10:8083/security/mibs/SYNOLOGY-DISK-MIB \
  -H "Authorization: Bearer <jwt-token>"

q is matched as a case-insensitive substring against object names. Always pass vendor when you can: with it the search covers one vendor’s modules, without it the whole catalogue, and that is the one operation whose cost grows with catalogue size. Everything else here is fast.

Extending the MIB catalogue

To add a vendor’s MIB, place its JSON module in the configured catalogue directory. New modules are picked up automatically, and changing the directory reloads the catalogue from the new location.

Keeping the catalogues current

Three of them can be replaced on a running probe, with no restart and no internet: the CVE feeds, the IEEE registry, and the vulnerability check template bundle. You bring the file to the probe by whatever means your site allows, and the probe takes it from there.

The CVE database

curl -sk -X POST https://192.168.1.10:8083/security/passive/cve-feeds \
  -H "Authorization: Bearer <jwt-token>" \
  -F 'file=@nvd-siemens.json'

Accepts a single feed file or the whole bundle. Ingestion is idempotent per feed: re-ingesting a feed deletes its previous rows before writing the new ones, so a CVE withdrawn upstream disappears here too rather than lingering as a stale finding. Add ?replace=true to empty the directory first instead of merging into it.

The IEEE manufacturer registry

curl -sk -X POST https://192.168.1.10:8083/security/oui-overlay \
  -H "Authorization: Bearer <jwt-token>" \
  -F 'file=@oui.csv'

Takes the IEEE file exactly as published. The next observed frame already resolves against it — there is no reload step.

It is validated on a copy before anything is replaced. A file that fails to yield a single usable assignment is rejected and the running registry is left untouched, so a truncated download cannot take your manufacturer resolution down with it.

The vulnerability check templates

curl -sk -X POST https://192.168.1.10:8083/security/vulnscan/templates/bundle \
  -H "Authorization: Bearer <jwt-token>" \
  -F 'file=@vulnscan-templates.tar.gz'

Checking what a probe actually has

curl -sk https://192.168.1.10:8083/security/passive/cve-feeds \
  -H "Authorization: Bearer <jwt-token>"

{ "dbFeeds": 18, "dbEntries": 55183, "directory": "/var/lib/axiom-border/cve-feeds",
  "feeds": [ { "name": "nvd-siemens.json", "entries": 1181, "size": 262144 } ] }

The same shape exists for /security/oui-overlay and /security/vulnscan/templates.

Why this is worth the disk it takes

Every catalogue here could have been a web service call. Making them local costs a few hundred megabytes and buys four things that matter in an industrial network:

1. The probe works where it is most needed. Isolated segments are isolated deliberately. A tool that phones out to stay useful is either useless there or a hole in the isolation.
2. Results are reproducible. The same probe, the same version, the same data, gives the same answer next month. A feed that silently moved underneath you does not.
3. Nothing about your network leaves it to be analysed. Resolving a vulnerability against a hosted service means telling that service what you have.
4. A scan cannot fail because something upstream was unreachable, renamed, or rate-limited.

And where the world genuinely does move — new CVEs, reassigned address blocks — you refresh it deliberately, on your own schedule, with a file you can inspect before you install it.

AI capabilities

Axiom Border can run machine-learning models on the probe, in containers, to detect anomalies in the metrics it ingests. A model trains locally on local data, exposes an inference endpoint on loopback, and rules call it to decide whether an event is worth an alarm.

The point is the same as everywhere else in the product: no cloud round trip, no data leaving the site.

Where you manage it

AI capabilities in the console lists the models configured on the probe. On a fresh installation it is empty, because model images are supplied separately from the product:

From here you create a capability, follow its training state, force or cancel a training run, edit the rule that calls the model, and read the quality metrics the model reports about itself. Everything on this page is done from that view — the sections below follow it in order.

The lifecycle

flowchart TB
    TAR["Model image tarball<br>supplied separately"]:::ext -->|"stage on disk"| IMG["Image imported<br>for one agent type"]
    IMG -->|"deploy"| EXPORT["Training data<br>exported"]
    EXPORT --> DEPLOY["Container deployed"]
    DEPLOY --> HEALTH{"Model<br>healthy?"}
    HEALTH -->|"not yet"| HEALTH
    HEALTH -->|"responds"| READY["READY"]
    READY -->|"retrain due"| TRAIN["TRAINING"]
    TRAIN --> READY
    READY -->|"predict"| INFER["Inference<br>from rules"]
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

Each agent type has a fixed loopback port, which is how a rule reaches the right model:

Each model listens on the host’s loopback address, so rules reach it at 127.0.0.1:<port>.

Loading a model image

Model images are not part of the installation bundle — they are supplied separately, because which model you run is a decision about your data rather than about the product.

Create new AI trainer collects everything needed in one step: the model package, and the agent type it applies to. You can upload the package from your machine, or tick Use file on disk and pick one already staged on the probe — the wizard lists what is there, with the directory it is reading.

Deploying a capability

The same wizard deploys it. Two settings decide how it behaves afterwards:

Deployment then does four things in order: exports the training data the probe already holds, starts the model with that data available to it, waits for the model to report itself healthy, and marks the capability ready — at which point it collects the model’s own quality metrics and enables the rule.

The health wait is bounded, roughly a minute and a half by default. A model that is slow to start needs that raised in Configuration; it is not a failure of the model.

Only one capability per agent type can exist at a time. Deploying over an existing one is refused — remove it first.

Following it from the console

The table on AI capabilities is the whole operational picture: trainer and model name, type, the retraining period, when it last ran and when it runs next, whether the script is enabled, the data source and inferencer, the model version, and the status.

Each row carries its actions:

Calling inference from rules

This is where the capability earns its place. A rule script fetches recent metrics, builds a feature vector, asks the model to score it, and raises an alarm when the model says anomaly:

function process(metrics) {
  for (var i = 0; i < metrics.length; i++) {
    var metric = metrics[i];
    metric.SetT0();

    var payload = JSON.stringify({
      sent_vars:     metric.GetFieldByName("sent_vars"),
      prepared_vars: metric.GetFieldByName("prepared_vars"),
      ram_usage:     metric.GetFieldByName("ram_usage")
    });

    var response = newPredict(payload, "metrics");
    var result   = JSON.parse(response);

    if (result.prediction === 1) {
      newAlarm(metric, "critical", "New anomaly detected", "Anomaly", "AI Capability");
    }

    metric.SetT1();
  }
}

Two globals are available to scripts for this: newPredict(payloadJSON, agentType) calls the model’s inference endpoint, and newGetMetrics(agentType) fetches the model’s own metrics. Both target the loopback port for that agent, and both are configured under trainerDetails.

The rule script for an agent is enabled through ruleEnabled when deploying the capability, and can be managed directly through the /scripts endpoints. See Alarms and rules.

Surviving a restart

Capabilities are part of the probe’s local state, and startup restores them: containers are resumed, model metrics are re-fetched, and retraining schedules resume from their stored next-run time.

One case is treated deliberately: a capability that was training when the process stopped is considered cancelled rather than resumed, because the training run did not finish. It moves to the appropriate cancelled state and waits for its next scheduled run.

Failures during this restoration are logged and do not prevent startup.

Configuration reference

The relevant block is trainerDetails — container name, TLS material, and the three endpoint definitions for health, metrics and inference. See Configuration.

The health, metrics and inference endpoints are meant to be reached over loopback only. Keep them bound to 127.0.0.1 and do not expose those ports beyond the host.

MQTT and OpenGate operations

Axiom Border carries its own MQTT broker, so a probe is a message bus as well as a monitoring probe. Three independent pieces make up the messaging layer:

On top of that sits the optional OpenGate integration, which reports inventory upward (collect) and registers devices (provision).

The local bus, first: scans publish their lifecycle, and anything that can connect to the broker can follow it.

flowchart TB
    SCAN["Security scans"] -->|"started<br>finishedok<br>failed"| EVC["Event client"]
    EVC --> BROKER["Embedded broker<br>loopback TCP 1883"]
    BROKER --> UI["Web console<br><i>via the API bridge</i>"]
    BROKER --> SUB["External<br>subscribers"]:::ext
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

Then the platform side, where OpenGate drives scans and receives inventory.

flowchart TB
    PLAT["OpenGate platform"]:::ext -->|"operation"| OPS["Operations client<br>odm/operation"]
    OPS -->|"launches"| SCAN2["Security scan"]
    OPS -->|"response"| PLAT
    INV["Provision and collect<br>inventory reports"] -->|"HTTP or MQTT"| PLAT
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

The embedded broker

The broker listens on loopback only, on TCP port 1883. It is not reachable from the network, and that is the shipped posture rather than a suggestion.

The console does not connect to it directly. It reaches the bus through a bridge inside the API’s own encrypted connection: the console asks for a single-use ticket that expires in seconds, and exchanges it when the connection is upgraded. So the live notifications you see in the console travel over the same authenticated, encrypted channel as everything else, and no separate port is opened for them.

A TLS listener on 8883 exists for the case where you genuinely need remote clients, including mutual TLS with client certificate verification. It is off by default.

Execution lifecycle events

Every security scan publishes its lifecycle to a single topic, mqtt.client.topic, which defaults to axiom-border/executions. This is the alternative to polling the executions API.

{
  "mode": "manual",
  "uuid": "4a79214d-3deb-4ae8-933f-9874cbdc1128",
  "event": "finishedok",
  "type": "networkscan",
  "elapsedTime": "5m18s",
  "details": "success"
}

Note that type here is networkscan, while the REST API reports the same scan as nmap. Map the two values if you correlate the event stream with the executions API.

Events are published on scan start, on completion, and on startup recovery for executions interrupted by a restart.

Events are published with the configured QoS (default 1) and retain flag (default true), and the client reconnects every 5 seconds while the broker is unreachable.

OpenGate operations over MQTT

The operations client lets the OpenGate platform trigger scans on the probe remotely. It subscribes to mqtt.ops.topicSubscribe (default odm/operation) and replies on mqtt.ops.topicPublish (default odm/response/{device-id}, with the device ID substituted at runtime).

Request envelope

{
  "operation": {
    "request": {
      "timestamp": 1730000000000,
      "name": "hostVulnScan",
      "id": "<operation-id>",
      "deviceId": "<device-id>",
      "parameters": { }
    }
  }
}

name, id and deviceId are all mandatory. A request missing any of them, or one that does not parse, is logged and silently ignored — no response is published. An unknown operation name does get a response, with ERROR_PROCESSING and Unsupported operation.

Response envelope

{
  "operation": {
    "response": {
      "name": "hostVulnScan",
      "timestamp": 1730000001000,
      "resultCode": "SUCCESSFUL",
      "resultDescription": "Success",
      "deviceId": "<device-id>",
      "id": "<operation-id>"
    }
  },
  "version": "1.0"
}

There are exactly two result codes: SUCCESSFUL and ERROR_PROCESSING.

The four operations

Both surfaces drive the same scan engine, so they share the same locking, history and safety gates. The differences are in what each surface exposes.

hostVulnScan takes targets, timeout, level, severity and intrusive — all optional. It does not expose templatesDir, so the configured resolution cascade always applies. The intrusive flag is gated by securityProbes.vulnScan.allowIntrusive exactly as over REST.

{
  "targets": ["192.168.1.0/24"],
  "level": "ot",
  "severity": "high,critical",
  "timeout": "10m",
  "intrusive": false
}

hostNetworkScan takes targets, timeout, timing and portFilter. Four options are fixed for MQTT-launched scans: port scanning is always on, OS detection is always on (which requires privileges), service detection is always off, and UDP is always off. There is no force equivalent either, so a scan launched while another manual network scan is running is rejected with ERROR_PROCESSING and manual network scan already running.

hostSnmpScan and hostSnmpWalkScan take targets, port, timeout, credentials in an snmp object, and either oids (mandatory for the GET) or walkRoot (defaulting to the enterprises subtree .1.3.6.1.4.1).

{
  "targets": ["192.168.1.50"],
  "port": 161,
  "timeout": "5m",
  "oids": ["sysDescr", "sysName"],
  "snmp": {
    "snmpVersion": "v2c",
    "community": "<snmp-community>"
  }
}

OpenGate provision and collect

Separate from operations, the integration reports upward on a schedule — and it is inert until you enable it. Everything it needs is on one screen, Configuration → OpenGate:

Below it, HTTPS transport security governs how the probe talks to the platform: whether a private certificate authority is needed, and whether the probe presents a client certificate of its own for mutual TLS.

Scheduling and throttling

A five-field cron expression (default */30 * * * *) drives both, with descriptors such as @hourly accepted. An empty or invalid expression means the integration does not run at all — check the log for a warning if nothing is happening.

minPeriod (default 30 minutes) is a floor: if the cron expression would fire more often than that, the schedule falls back to a fixed interval of minPeriod and logs a warning. Cycles never overlap — a cycle due while the previous one is still running is skipped and logged.

Provision

Provisioning registers discovered hosts with the platform. It builds an Excel workbook — one row per host, with device ID, addressing, state and the location metadata from opengate.collect.address — and uploads it to the bulk endpoint.

The upload requires exactly 201 Created; anything else aborts the provision. The result is then polled up to pollMaxAttempts times (default 10, every 5 seconds), and only counts as success when the platform reports every submitted host as successful.

Provision is HTTP only — there is no MQTT variant.

Collect

Collect sends the accumulated per-host inventory: identity, ports, vulnerabilities and SNMP entries, with timestamps.

{
  "deviceId": "192.168.1.50-00.11.22.33.44.55",
  "ipAddress": "192.168.1.50",
  "macAddress": "00:11:22:33:44:55",
  "specificType": "HOST",
  "hostname": "plc-line-1",
  "os": "Linux 4.x",
  "manufacturer": "Siemens AG",
  "status": "up",
  "ports": [ { "portNumber": 502, "protocol": "tcp", "service": "mbap", "status": "open" } ],
  "vulnerabilities": { "hasVulns": true, "catList": "medium,high", "highDetect": "high", "vulnList": [ ] },
  "snmp": [ { "oid": ".1.3.6.1.2.1.1.1.0", "name": "sysDescr", "value": "..." } ]
}

Transport is chosen by collect.mode: mqtt, or http for anything else including an empty value. Over HTTP the payload is posted with the X-ApiKey header; over MQTT it is published to collect.mqtt.topic, falling back to opengate.apiKey as the password when no MQTT password is set.

Chunking. With collect.sendByParts: true, each host is split into several messages: a header with the scalar fields plus one chunked block at a time — ports, then SNMP, then vulnerabilities — sized by collect.partSize.* (default 100 each). This matters on metered or constrained links where a host with hundreds of findings would otherwise produce one oversized message. With chunking off, each host is a single message.

A failed chunk is logged and the cycle continues with the next one, so one bad message does not abort the whole report.

Device identity

The device ID is derived per host as <ip>-<MAC with dots>, for example 192.168.1.50-00.11.22.33.44.55. Hosts without a discoverable MAC get the placeholder AA.BB.CC.DD.EE.FF. This is the same format accepted by GET /security/results/last?deviceId=, so an ID seen in the platform can be looked up on the probe directly.

Before each cycle, hosts missing a MAC or hostname get a quick nmap ping scan to fill the gaps, bounded by macDiscoveryTimeout (default 10 s).

Configuration reference

Everything here is configured under the mqtt and opengate blocks. See Configuration for the field-by-field tables, including the TLS options and the retry parameters for both provision and collect.

Operation and maintenance

Service commands

Each role installs a different set of units. The standard systemd verbs apply to all of them:

sudo systemctl status axiom-border
sudo systemctl restart axiom-border
sudo systemctl is-active axiom-border
sudo systemctl is-enabled axiom-border

The units, depending on role: axiom-border, axiom-influxdb, containerd, oda-lite.

Where the logs live

This is the single most useful thing to know when something misbehaves, because the important detail is not in the journal:

Everything at once, which is often what you want:

sudo journalctl -u axiom-border -u axiom-influxdb -u containerd -u oda-lite \
  --since "5 minutes ago" --no-pager

Log levels

Axiom Border — the logger block of configuration.yaml. Set logLevel to DEBUG, INFO, WARN or ERROR, then restart the service. See Configuration.

oda-lite agent — /etc/oda-lite/oda-lite.conf, [agent] section: log_level and debug. Restart the service afterwards.

InfluxDB and containerd — the level comes from binary flags in the unit file. Changing it means editing the unit, and is not recommended.

Rotation and disk usage

Axiom Border’s own log rotates through the logger settings: maxSize (MB per file, default 20), maxBackups (default 20) and compress (gzip the rotated files).

The journald drop-in installed by the bundle is global — SystemMaxUse=500M and MaxFileSec=1day apply to the entire host journal, not only to Axiom Border. On a host sharing other workloads, adjust it or replace it with per-unit drop-ins.

journalctl --disk-usage
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=7d

To see what is consuming space:

du -sh /var/log/oda-lite /opt/axiom-border/logs /var/log/journal/

Backup and restore

Stop the service first, for a consistent snapshot:

sudo systemctl stop axiom-border
sudo tar -czf /path/backup-axiom-border-$(date +%F).tar.gz \
  /opt/axiom-border/config /opt/axiom-border/db.dat /var/lib/influxdb2
sudo systemctl start axiom-border

Restore is the inverse:

sudo systemctl stop axiom-border
sudo tar -xzf backup-axiom-border-<date>.tar.gz -C /
sudo systemctl start axiom-border

Offline maintenance

Refreshing the data the security probes read

Three things the probe reads off disk are facts about the world that change on their own: the vulnerability templates, the local CVE database, and the IEEE OUI registry. All three ship with the bundle, so a freshly installed probe already works. All three can be refreshed through the API, without restarting the service and without an SSH session — which is the point, because the probe is designed for a network with no route to the internet.

Vulnerability templates

# What is installed right now
curl -sk https://<probe>:8083/security/vulnscan/templates -H "Authorization: Bearer $JWT"

# Offline refresh — the mode that matters on an air-gapped probe
curl -sk -X POST https://<probe>:8083/security/vulnscan/templates/bundle \
  -H "Authorization: Bearer $JWT" -F "file=@vulnscan-templates.tar.gz"

The archive is expanded and validated in full in a separate directory, the product’s own OT/ICS templates are re-mirrored on top of it, and only then is it swapped in atomically. A corrupt, empty or traversal-carrying archive is rejected with 400 and the previous templates still serving. The response reports what ended up active; a non-zero otTemplates is the check that the OT set survived the replacement.

The upstream mode (POST /security/vulnscan/templates/update) needs connectivity and allowTemplateUpdates: true. On a standard deployment it answers 409 and points at the bundle route.

Both modes are serialised against a running scan, and the exclusion waits before giving up: the request blocks for up to 20 s and only then returns 409.

otTemplates: 0 on a freshly installed probe is normal — the OT templates live inside the binary and are written to the directory on the first scan. A zero after an update is not.

Local CVE database

curl -sk https://<probe>:8083/security/passive/cve-feeds -H "Authorization: Bearer $JWT"

# One vendor, merged into what is already there
curl -sk -X POST https://<probe>:8083/security/passive/cve-feeds \
  -H "Authorization: Bearer $JWT" -F "file=@nvd-siemens.json"

# The whole base, guaranteeing nothing older survives
curl -sk -X POST 'https://<probe>:8083/security/passive/cve-feeds?replace=true' \
  -H "Authorization: Bearer $JWT" -F "file=@cve-feeds.tar.gz"

Ingested immediately, no restart. The status reports both the files on disk and the rows in the database: the two disagreeing is exactly the symptom of “the feeds are there but nothing seeded them”. If a single file in the upload does not parse as a feed the whole upload is rejected — half a CVE base is worse than none, because the probe then reports fewer vulnerabilities than there are and looks like it worked.

OUI registry (manufacturer by MAC)

The table compiled into the binary freezes at each release while the IEEE republishes every few days. The registry on disk is laid on top of it: it wins for the prefixes it carries, everything else keeps resolving from the built-in table. Removing it leaves nobody without a manufacturer.

curl -fLO https://standards-oui.ieee.org/oui/oui.csv        # on a machine with internet
curl -sk -X POST https://<probe>:8083/security/oui-overlay \
  -H "Authorization: Bearer $JWT" -F "file=@oui.csv"

The file is accepted exactly as the IEEE publishes it, so what you installed can be diffed against the source. It takes effect on the next frame. The response counts what it contributes: newPrefixes (hardware currently reported with no manufacturer at all), overrides, and renames — the last being the number that matters, since it is how many devices are about to be reported under a different manufacturer. Hosts resolved this way publish manufacturerSource: "oui-overlay".

Only MA-L assignments are read. MA-M and MA-S share a 24-bit prefix between several companies, so including them would credit one company’s block to another.

Loading AI images

AI images are not part of the bundle — they are distributed separately as OCI tarballs, and resources/iaimages/ ships empty as a placeholder.

sudo nerdctl --namespace axiom-border image load -i <image>.tar
sudo nerdctl --namespace axiom-border image ls

Upgrading

Extract the new bundle of the same role on the target and run upgrade.sh. It aborts if the bundle role does not match the installed role — changing role requires uninstall followed by install.

sudo ./upgrade.sh

What it does: verifies the previous installation and role match, stops the role’s services (leaving InfluxDB and containerd running, so data in flight is not disturbed), takes timestamped backups of the binary and db.dat, replaces the binary and updatable assets, starts the service, and health-checks it.

Preserved across upgrade: config/, db.dat, .influx-creds, parquet/, logs/, /var/lib/influxdb2/, resources/iaimages/ and the oda-lite configuration.

Replaced: the binary, MIBS/, resources/gojascripts/, vulnscan-templates/, the documentation and the lifecycle scripts.

Uninstalling

sudo /opt/axiom-border/uninstall.sh

It stops and disables the role’s services, removes only the units it created, removes the journald and sshd drop-ins, and asks whether to keep the data — InfluxDB data, db.dat, logs and configuration.yaml. Answer non-interactively with AXIOM_KEEP_DATA=true|false.

It removes shared binaries only where the manifest marks them as installed by this deployment. It does not remove nmap, rsyslog or network-manager even if it installed them — those are host infrastructure and are left to the operator. It does not revert the netplan switch by default.

Running it on a clean system is safe and idempotent: it reports there is nothing to uninstall and exits 0.

AXIOM_RESTORE_NETPLAN=1 warns about possible connectivity loss. In practice an established SSH session usually survives, since the TCP connection is not torn down and the IP is retained — but do not count on it over a link you cannot recover from out-of-band.

Troubleshooting by symptom

Quick triage

Detailed cases

The service will not start. Three usual causes: the binary lost its execute bit (chmod +x /opt/axiom-border/axiom-border), a required port is occupied, or the YAML is invalid. Validate the configuration directly:

python3 -c "import yaml; yaml.safe_load(open('/opt/axiom-border/config/configuration.yaml'))"

Login fails with the correct password. login.pass must be the SHA-256 digest, not the plaintext. Recalculate and restart:

echo -n "<your-password>" | sha256sum | awk '{print $1}'

A port is in use. Identify the holder, then either stop it or move the Axiom Border port:

sudo ss -tlnp | grep -E ':(8083|1883|1888|8086|9090|9091) '

Ports 8083, 1883 and 1888 move via apiPort, mqtt.broker.port and mqtt.broker.ws.port. Ports 9090 and 9091 move in /etc/oda-lite/oda-lite.conf.

Vulnerability scans return zero findings, suspiciously. The web template directory is probably empty or incomplete:

ls /opt/axiom-border/vulnscan-templates/ | head

It should list per-protocol directories such as http/, network/ and ssl/. CVE templates live under http/cves/, not at the root. Refresh them as described above. OT/ICS findings are unaffected, because that suite ships with the product.

Sniffing captures nothing. Check the interface exists (ip -o link show), that the service runs as root (systemctl show axiom-border -p User), and that there is actually traffic (sudo tcpdump -i <iface> -c 10).

The UI loads but every API call returns 401. The JWT is missing or expired. Clear the browser’s localStorage and log in again.

nmap probes hang or take very long. A large target range with poor reachability, a high timeout, or udp: true with many ports. Narrow the range, lower the timeout, disable UDP.

High memory usage. Check for an AI capability working a large dataset, an Influx bucket with no retention policy, or logLevel: DEBUG left on.

“Orphaned installation detected.” Bundle artefacts exist without an .install-manifest. Three ways out: AXIOM_CLEAN_RESIDUALS=1 sudo bash install.sh moves the leftovers aside, sudo bash upgrade.sh preserves data, sudo bash uninstall.sh cleans best-effort.

upgrade.sh exits with code 2 reporting a rollback. The new binary failed its health check and the old one is back in service. Diagnose with the journal, the application log and the install log, then retry with a corrected bundle.

The monitoring node floods the journal with “connection refused” to port 9090. The central node is not up, a firewall blocks it, or the URL is wrong. The agent keeps retrying and buffers metrics while it waits, so a short outage loses nothing — a long one eventually will.

Error executing 'netstat': exit status 1. Minimal Ubuntu Server images lack net-tools. Not blocking — the other plugins continue:

sudo apt-get install -y net-tools && sudo systemctl restart oda-lite

NetworkManager is active but interfaces show as unmanaged. The netplan renderer was not switched over. Re-run install.sh --switch-to-network-manager; it detects the current state and completes the switch without reinstalling NetworkManager.

/etc/oda-lite/oda-lite.conf.new contains literal ${VARIABLE} placeholders. The file is an unexpanded template. Do not copy it over the live configuration — the agent would not start. Delete it and re-run the upgrade with the current bundle.

scp or tar -xzf fail with Permission denied in /tmp. Some base images ship /tmp with wrong permissions. It should be drwxrwxrwt:

ls -ld /tmp
sudo chmod 1777 /tmp