Skip to content
Agents & Probes

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).

ComponentRuns onPurpose
Aethis AgentIndividual monitored hostsLocal system metrics, Nagios-plugin checks, web analytics
Aethis ProbeA network segment (one host with visibility into the segment)Passive packet capture, NetFlow/IPFIX/sFlow ingestion, device/traffic classification
Perimeter ProbeExternally, operated separately from a tenant’s own infrastructureOn-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-SERVER

Useful flags:

  • --insecure — skip TLS verification (self-signed backend certs)
  • --token TOKEN — register with a pre-issued token instead of interactive pairing (--no-pair is 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 installing monitoring-plugins/nagios-plugins via 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: true

Additional 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: info

Events 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.key

Run it as a container:

docker run -d --name perimeter-probe \
  -v /etc/perimeter-probe:/etc/perimeter-probe:ro \
  -p 8443:8443 \
  perimeter-probe:latest

Certificate 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

  1. The probe operator generates a tenant client certificate + key.
  2. 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 as sha256:<hex>), and the tenant’s client certificate + key (PEM).
  3. The tenant runs a scan from /discovery/perimeter in 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.