Agents & Probes
Overview
Three standalone Go binaries extend Eon Aethis beyond the central platform. All of them initiate outbound connections to the backend — none requires an inbound port to be opened on the host or network they run on, except the Perimeter Probe, which is deployed the other way around (see below).
| Component | Runs on | Purpose |
|---|---|---|
| Aethis Agent | Individual monitored hosts | Local system metrics, Nagios-plugin checks, web analytics |
| Aethis Probe | A network segment (one host with visibility into the segment) | Passive packet capture, NetFlow/IPFIX/sFlow ingestion, device/traffic classification |
| Perimeter Probe | Externally, operated separately from a tenant’s own infrastructure | On-demand external reconnaissance scans against a tenant’s public-facing assets |
Aethis Agent
Installed with a one-liner that downloads the platform-matched binary from the backend itself:
curl -sSL https://YOUR-SERVER/agents/install.sh | bash -s -- --server https://YOUR-SERVERUseful flags:
--insecure— skip TLS verification (self-signed backend certs)--token TOKEN— register with a pre-issued token instead of interactive pairing (--no-pairis implied)--no-pair— install the binary and systemd unit without registering--config PATH— config file path (default/etc/eon-aethis/eon-aethis.conf)--no-plugins— skip installingmonitoring-plugins/nagios-pluginsvia the host package manager (apt/dnf/yum/apk, whichever is present)--with-geoip— download the DB-IP Lite City database for web-analytics geolocation--uninstall— stop, disable, and remove the agent (leaves the config file behind)
The installer detects linux-amd64/linux-arm64, requires systemd and
root, installs the binary to /usr/local/bin/aethis-agent, links any
discovered Nagios-compatible check_* plugins into
/usr/lib/eon-aethis/plugins, and installs an
eon-aethis-agent.service systemd unit. Pairing (the default flow when
--token isn’t given) requires approval in the Eon Aethis UI before the
config file — and therefore the running service — is created.
The generated config (YAML, at --config’s path):
server:
url: "https://YOUR-SERVER"
token: "<issued during pairing or --token>"
tls_verify: true # false when installed with --insecure
checks:
interval: "60s"
plugins_dir: "/usr/lib/eon-aethis/plugins"
metrics:
cpu: true
memory: true
disk: true
network: true
processes: trueAdditional fields available in the config schema but not written by the
installer: checks.system_plugins_dir, checks.plugins (a list of
{name, path, args, interval} for custom checks), agent.hostname,
agent.tags (a map of key/value tags), and web_analytics (enabled,
access_logs: [{path, format, name}], geoip_db, interval) for parsing a
local web server’s access logs. agent.probe_port/agent.probe_enabled are
legacy fields kept for backwards compatibility — active network scanning
has moved to the Aethis Probe and is disabled here by default.
Aethis Probe
Passively observes a network segment: live packet capture, NetFlow/IPFIX/ sFlow listeners, ARP/DHCP analysis, and traffic classification, buffered locally and pushed to the backend. Install as root:
BACKEND_URL=https://YOUR-SERVER ./install.sh(install.sh ships in probe/dist/ next to the eon-aethis-probe binary
and its systemd unit; set BIN_URL instead of placing the binary alongside
the script if you’re fetching it remotely.) Set INSECURE=1 to skip TLS
verification for a self-signed backend during testing — this also passes
--insecure to the pairing step.
The installer creates a dedicated eon-probe system user, installs the
binary to /usr/local/bin/eon-aethis-probe, writes
/etc/eon-aethis-probe/probe.yaml from the template (owned root:eon-probe,
mode 0640), installs the eon-aethis-probe.service systemd unit, and runs
the pairing flow — which must be approved in the backend UI — before
enabling the service.
Config reference (/etc/eon-aethis-probe/probe.yaml):
backend_url: https://aethis.example.com
probe_id: "" # filled in by the pairing flow
auth_token: "" # filled in by the pairing flow
ca_path: "" # CA cert for a self-signed backend
tls_verify: true # set false only for --insecure test setups
push_interval: 60s # how often buffered events are pushed
buffer_path: /var/lib/eon-aethis-probe/buffer.db
buffer_max_events: 100000
buffer_max_bytes: 104857600 # 100 MB
interfaces:
- name: eth0
mode: host
bpf: "" # optional BPF filter
control_port: 9202 # local diagnostics API
log_level: infoEvents are buffered in a local SQLite database (buffer_path) so a
temporary backend or network outage doesn’t drop data; the buffer is capped
by both event count and byte size, dropping oldest events past either
limit.
Perimeter Probe
A multi-tenant reconnaissance service, deployed separately from any single tenant’s Eon Aethis instance (typically operated centrally, e.g. one probe serving many customers). It authenticates every call with mutual TLS: an operator-controlled CA signs a server certificate for the probe and a distinct client certificate per tenant, and the probe reads the tenant ID directly from the client certificate’s CN on each incoming job request — there is no separate tenant-ID field to trust.
Config (/etc/perimeter-probe/probe.yaml):
addr: ":8443"
server_cert: /etc/perimeter-probe/server.crt
server_key: /etc/perimeter-probe/server.key
operator_ca: /etc/perimeter-probe/operator-ca.crt
client_cert: /etc/perimeter-probe/client.crt
client_key: /etc/perimeter-probe/client.keyRun it as a container:
docker run -d --name perimeter-probe \
-v /etc/perimeter-probe:/etc/perimeter-probe:ro \
-p 8443:8443 \
perimeter-probe:latestCertificate CN conventions used by the operator when issuing certs (with
cfssl or similar):
- Operator CA:
CN=eon-aethis-perimeter-ca - Probe server cert:
CN=perimeter-probe-1 - Probe client cert (for its outbound callbacks):
CN=perimeter-probe-1-client - Tenant client cert:
CN=tenant-<slug>(e.g.tenant-acme)
Tenant onboarding
- The probe operator generates a tenant client certificate + key.
- The tenant creates a Perimeter Probe pairing in their Eon Aethis UI
(
/admin/perimeter-probes), supplying: the probe’s base URL (https://<probe-host>:8443), the operator CA certificate (PEM), the probe’s certificate fingerprint (openssl x509 -in server.crt -outform DER | openssl dgst -sha256, formatted assha256:<hex>), and the tenant’s client certificate + key (PEM). - The tenant runs a scan from
/discovery/perimeterin the Eon Aethis UI.
Certificate rotation
- Tenant cert: re-paste the new cert in the admin UI; the old one remains recorded in the database until explicitly cleared.
- Probe server cert: replace the files on the probe host and restart it; every tenant must then update their pinned fingerprint.
- Operator CA: high-touch — requires issuing new tenant and probe certificates from the new CA and cycling all of them.