Rublon Log Sync

Last updated on September 28, 2026

Overview

Rublon Log Sync is a Linux application that retrieves logs from the Rublon Admin API and forwards them to a Security Information and Event Management (SIEM) system.

You can use Rublon Log Sync to continuously export the following types of Rublon MFA logs:

• Audit Logs
• Authentication Logs
• Phone Logs
• Activity Logs

Rublon Log Sync supports multiple independent synchronization jobs. Each job can retrieve one or more log types and forward them to a configured SIEM target over TCP.

The application can send records as compact JSON or Common Event Format (CEF) version 1 messages. JSON and CEF payloads can be sent without a syslog envelope, with a shortened syslog prefix, or with a complete RFC 5424 syslog envelope.

How Does Rublon Log Sync Work?

Rublon Log Sync performs the following operations:

1. Connects to the Rublon Admin API using the System Token and Secret Key of an application of type Admin API.
2. Retrieves records from the configured audit, authentication, phone, and activity endpoints.
3. Converts the records to the configured output format.
4. Sends the resulting messages to the configured SIEM target over TCP.
5. Stores checkpoint cursors when checkpointing is enabled.
6. Uses the saved checkpoints to continue synchronization from the last successfully processed position.

Two modes are available:

• In continuous mode, every synchronization job runs repeatedly according to its configured interval.
• In one-shot mode, the application runs one synchronization cycle and then exits.

Each SIEM message is sent as one UTF-8 line over TCP. One produced batch opens one TCP connection to the configured target. Empty batches do not open a TCP connection.

Log Sync Diagram

Supported Logs

Rublon Log Sync supports the following Rublon Admin API log endpoints:

Endpoint Type	Rublon Log Type	Maximum API Lookback
audit	Audit Logs	365 days
authentication	Authentication Logs	180 days
phone	Phone Logs	365 days
activity	Activity Logs	365 days

The maximum lookback determines how far into the past a new synchronization job can retrieve records when no compatible checkpoint exists.

Phone Log Availability and Event Ordering

Phone Logs may become available through the Rublon Admin API later than the events they describe. The API waits for an external telecommunications service provider to report information about an SMS or phone call, including its cost. Provider updates can take two minutes or longer. Once a record becomes available, Rublon Log Sync can retrieve it in a subsequent synchronization cycle.

Rublon Log Sync forwards records in the order returned by the API and does not sort them by event time. This applies to both payload formats (json and cef) and all envelopes (bare, partial_syslog, and rfc5424). A Phone Log for an earlier event may therefore reach the SIEM after records for later events.

For records with a valid createdAt value, the partial_syslog and rfc5424 envelopes use the original event time as the Syslog timestamp. Configure your SIEM to use this timestamp when sorting events chronologically. For bare payloads, the event time is available in the JSON createdAt field or the CEF rt field. The SIEM’s parser and display settings determine whether it uses event time or receipt time.

If the provider’s update does not arrive within the Admin API’s safety window, the API may release the record without waiting longer.

Supported Output Formats

Rublon Log Sync supports the following SIEM payload formats:

Format	Description
json	Preserves the complete Rublon Admin API record as compact, strict JSON.
cef	Converts the record to Common Event Format version 1 (CEF:1) according to the endpoint-specific mapping rules described in the CEF Mapping section.

The payload can use one of the following envelopes:

Envelope	Description
bare	Sends the serialized JSON or CEF payload without a syslog envelope.
partial_syslog	Adds a shortened syslog prefix containing <PRI>, syslog version 1, a timestamp, and a hostname.
rfc5424	Wraps the payload in a complete RFC 5424 syslog envelope.

The selected envelope is independent of the selected JSON or CEF payload format.

Tested SIEM Systems

Rublon Log Sync has been tested with the following platforms:

• Graylog
• Wazuh

For other SIEM systems, compatibility depends on the configured ingestion method and accepted message format. Contact Rublon Support to discuss your environment and integration requirements.

Before You Start

Before installing Rublon Log Sync:

1. Create a Rublon MFA organization if you do not already have one.
2. Create an application of type Admin API in the Rublon Admin Console and copy its System Token and Secret Key.
3. Prepare a Linux server on which Rublon Log Sync will run as a systemd service.
4. Prepare a SIEM target that can receive newline-delimited messages over TCP.
5. Ensure that the Linux server can connect to the configured Rublon API server over HTTPS and to the SIEM target on the configured TCP port.

Create a Rublon MFA Organization

To use Rublon Log Sync, you need a Rublon MFA organization in the Rublon Admin Console.

If you do not have an organization yet, refer to Rublon Admin Console – Rublon MFA Account Registration for instructions.

Get the Admin API Credentials

1. Sign in to the Rublon Admin Console.
2. Go to Applications.
3. Click Add Application.
4. Enter a name for the application, for example, Rublon Log Sync.
5. Set Type to Admin API.
6. Click Save.
7. Copy the System Token and Secret Key from the API Credentials section. You will use these values in the Rublon Log Sync configuration.

Prepare the SIEM Target

Before configuring Rublon Log Sync, prepare the following information:

• SIEM target hostname or IP address
• TCP port
• Required payload format: JSON or CEF
• Required envelope: bare, partial syslog, or RFC 5424

Rublon Log Sync currently supports TCP as the SIEM transport protocol.

Installing Rublon Log Sync

Rublon Log Sync can be installed from the standalone Linux package as a systemd service.

The service runs as a dedicated, unprivileged system user. The installer separates application files, configuration, runtime state, and operational logs into standard Linux directories.

Install the Package

1. Download the latest Rublon Log Sync Linux package from Rublon Downloads.

2. Extract the package:

tar -xzf rublon-log-sync-<version>-linux-<arch>.tar.gz

Note: Replace <version> and <arch> with the appropriate values for your package, for example:

tar -xzf rublon-log-sync-1.1.0-linux-x86_64.tar.gz

3. Go to the extracted directory:

cd rublon-log-sync-<version>-linux-<arch>

4. Run the installer:

sudo bash scripts/install-linux.sh --artifact bin/rublon-log-sync

The --artifact value must point to the executable that will be installed as:

/opt/rublon-log-sync/bin/rublon-log-sync

By default, the installer:

• creates the rublon-log-sync system user and group if they do not exist;
• creates the application, configuration, runtime state, and log directories;
• copies the example configuration to /etc/rublon-log-sync/config.example.yaml;
• does not create or overwrite /etc/rublon-log-sync/config.yaml;
• installs the systemd service unit;
• reloads the systemd manager configuration;
• does not start or enable the service automatically.

File Layout

Path	Purpose
/opt/rublon-log-sync	Application installation directory.
/opt/rublon-log-sync/bin/rublon-log-sync	Rublon Log Sync executable.
/etc/rublon-log-sync/config.yaml	Production configuration file.
/etc/rublon-log-sync/config.example.yaml	Example configuration installed with the package.
/etc/rublon-log-sync/rublon-log-sync.env	Optional environment file for secrets.
/var/lib/rublon-log-sync/checkpoints	Checkpoint state directory.
/var/log/rublon-log-sync	Application log directory.
/etc/systemd/system/rublon-log-sync.service	Installed systemd service unit.

After installing Rublon Log Sync, create the production configuration file and configure access to the Rublon Admin API and your SIEM target. Refer to the Configure Rublon Log Sync section for instructions.

Configure Rublon Log Sync

Rublon Log Sync reads its settings from a YAML configuration file.

The Linux service uses:

/etc/rublon-log-sync/config.yaml

After changing the configuration, restart the service for the new settings to take effect:

sudo systemctl restart rublon-log-sync

Create the Configuration File

1. Create the configuration file used by the service:

sudo install -o root -g rublon-log-sync -m 0640 \
  /etc/rublon-log-sync/config.example.yaml \
  /etc/rublon-log-sync/config.yaml

2. Then, open the file for editing:

sudo editor /etc/rublon-log-sync/config.yaml

3. Configure access to the Rublon Admin API, synchronized log endpoints, SIEM targets, application logging, proxy settings, and checkpoint behavior. Refer to the Configuration Sections for more information on each section.

Minimal Configuration Example

log:
  debug: false
  log_files_count: 7
  syslog_enabled: false

global:
  secret_source: env

rublon:
  api_server: https://core.rublon.net
  system_token: "RUBLON_ADMIN_API_SYSTEM_TOKEN"
  secret_key: "RUBLON_ADMIN_API_SECRET_KEY"

sync_jobs:
  - id: "main"
    checkpoint_enabled: true
    rublon_endpoints:
      - type: audit
      - type: authentication
      - type: phone
      - type: activity
    interval: 60
    per_page: 100
    target:
      hostname: "127.0.0.1"
      port: 1514
      protocol: TCP
      format: json
      envelope: bare

Store Admin API Credentials in Environment Variables

For production deployments, we recommend loading the Rublon Admin API credentials from environment variables.

1. Create an environment file:

sudo touch /etc/rublon-log-sync/rublon-log-sync.env
sudo chown root:rublon-log-sync /etc/rublon-log-sync/rublon-log-sync.env
sudo chmod 0640 /etc/rublon-log-sync/rublon-log-sync.env

2. Edit the file:

sudo editor /etc/rublon-log-sync/rublon-log-sync.env

3. Add the credentials:

RUBLON_ADMIN_API_SYSTEM_TOKEN=your-system-token
RUBLON_ADMIN_API_SECRET_KEY=your-secret-key

4. Create a systemd drop-in override:

sudo systemctl edit rublon-log-sync

5. Add:

[Service]
EnvironmentFile=/etc/rublon-log-sync/rublon-log-sync.env

6. Reload systemd:

sudo systemctl daemon-reload

7. Configure the following values in /etc/rublon-log-sync/config.yaml:

global:
  secret_source: env

rublon:
  api_server: https://core.rublon.net
  system_token: "RUBLON_ADMIN_API_SYSTEM_TOKEN"
  secret_key: "RUBLON_ADMIN_API_SECRET_KEY"

Note: When secret_source is set to env, the system_token and secret_key values are environment variable names, not the credentials themselves.

Configuration Sections

The configuration file contains the following top-level sections:

• log
• global
• rublon
• sync_jobs

Section: log

The optional log section controls Rublon Log Sync operational logging.

Field	Required	Default	Description
debug	No	false	Enables debug-level application logging.
log_files_count	No	7	Number of archived daily log files to retain. Must be a positive integer.
syslog_enabled	No	false	Sends application diagnostics to the local Linux syslog service when available.

Example:

log:
  debug: false
  log_files_count: 7
  syslog_enabled: false

Application diagnostics are written to rublon-log-sync.log in the configured logs directory. In the Linux service installation, the file is located at:

/var/log/rublon-log-sync/rublon-log-sync.log

Warnings and errors are also written to stderr and collected by journald when the application runs as a systemd service.

Section: global

The optional global section contains settings shared by the application.

Field	Required	Default	Description
secret_source	No	plain	Determines how rublon.system_token and rublon.secret_key are resolved. Allowed values: plain, env.
proxy_url	No	none	Proxy server used for outbound Rublon Admin API requests.

If the global section is omitted, Rublon Log Sync behaves as if the following configuration were present:

global:
  secret_source: plain

Secret Source

With secret_source: plain, the rublon.system_token and rublon.secret_key values are treated as literal credentials stored in the YAML file.

With secret_source: env, they are treated as environment variable names. The application will not start if either variable is missing or empty.

For production deployments, use secret_source: env whenever possible.

Proxy Server

Use global.proxy_url to configure one proxy server for all outbound Rublon Admin API requests.

You can use the host:port shorthand:

global:
  proxy_url: "proxy.example.com:8080"

The shorthand is interpreted as:

http://proxy.example.com:8080

You can also use an explicit HTTP or HTTPS URL:

global:
  proxy_url: "http://proxy.example.com:8080"

global:
  proxy_url: "https://proxy.example.com:8443"

The scheme defines the connection between Rublon Log Sync and the proxy. The connection to the Rublon Admin API still uses HTTPS.

Proxy credentials can be included in the URL:

global:
  proxy_url: "https://user:password@proxy.example.com:8443"

Section: rublon

The required rublon section configures access to the Rublon Admin API.

Field	Required	Description
api_server	Yes	Rublon API server base URL. It must use HTTPS and contain only a scheme, hostname, and optional port. Do not include an endpoint path, query string, username, or password.
system_token	Yes	Admin API System Token or environment variable name, depending on global.secret_source.
secret_key	Yes	Admin API Secret Key or environment variable name, depending on global.secret_source.

Example:

rublon:
  api_server: https://core.rublon.net
  system_token: "RUBLON_ADMIN_API_SYSTEM_TOKEN"
  secret_key: "RUBLON_ADMIN_API_SECRET_KEY"

Section: sync_jobs

The required sync_jobs section is a non-empty list of synchronization jobs.

Each synchronization job retrieves one or more Rublon MFA log types and sends the records to one SIEM target.

Field	Required	Default	Description
id	Yes	none	Unique, non-empty synchronization job identifier.
checkpoint_enabled	No	true	Saves synchronization progress and resumes from the saved position.
rublon_endpoints	Yes	none	Non-empty list of Rublon MFA log endpoints. Endpoint types must be unique within one job. Supported endpoint types: audit, authentication, phone, activity.
interval	No	60	Delay in seconds after each continuous-mode synchronization cycle. Must be an integer of at least 60.
per_page	No	100	Number of records requested per API page. Allowed range: 15 to 1000
from_datetime	No	none	Initial lower timestamp bound in %Y-%m-%d %H:%M:%S format. It must not be in the future.
target	Yes	none	SIEM target configuration.

Example with two independent synchronization jobs:

sync_jobs:
  - id: "security-logs"
    checkpoint_enabled: true
    rublon_endpoints:
      - type: audit
      - type: authentication
    interval: 60
    per_page: 100
    target:
      hostname: "siem.example.com"
      port: 1514
      protocol: TCP
      format: cef
      envelope: rfc5424

  - id: "phone-logs"
    checkpoint_enabled: true
    rublon_endpoints:
      - type: phone
    interval: 300
    per_page: 100
    target:
      hostname: "siem.example.com"
      port: 1515
      protocol: TCP
      format: json
      envelope: bare

from_datetime and API Lookback Limits

from_datetime specifies the initial lower timestamp bound when an endpoint does not have a compatible checkpoint cursor.

The Rublon Admin API applies the following maximum lookback periods:

Endpoint	Maximum Lookback
audit	365 days
authentication	180 days
phone	365 days
activity	365 days

For a new job, from_datetime must be within the lookback limit of every configured endpoint. When a job contains multiple endpoint types, the most restrictive limit applies to the entire job. For example, a job containing audit, authentication, phone, and activity is limited to 180 days because the Authentication Logs endpoint has a 180-day lookback limit.

If from_datetime exceeds the limit for one endpoint and that endpoint does not have a compatible checkpoint, the entire job fails to start. Rublon Log Sync does not partially start only the endpoints whose limits are satisfied.

When a compatible checkpoint exists, synchronization resumes from the checkpoint and from_datetime is not used for that endpoint.

To retrieve Audit Logs, Phone Logs, or Activity Logs over a longer initial period while retrieving Authentication Logs over a shorter period, create separate synchronization jobs with different from_datetime values.

Section: target

Every synchronization job requires one target object.

Field	Required	Default	Description
hostname	Yes	none	SIEM target hostname, IPv4 address, or IPv6 address. Do not include a URL scheme or port.
port	Yes	none	SIEM target TCP port. Allowed range: 1 to 65535
protocol	Yes	none	SIEM transport protocol. Currently, only TCP is supported.
format	No	json	Payload format. Allowed values: json, cef
envelope	No	bare	Payload envelope. Allowed values: bare, partial_syslog, rfc5424

Example:

target:
  hostname: "siem.example.com"
  port: 1514
  protocol: TCP
  format: cef
  envelope: partial_syslog

Payload Envelopes

• The bare envelope sends only the serialized JSON or CEF payload.
• The partial_syslog envelope adds the following shortened prefix: <PRI>1 TIMESTAMP HOSTNAME PAYLOAD
  • partial_syslog is an application-specific shortened envelope accepted by some SIEM systems. It is not a separate syslog standard.
• The rfc5424 envelope wraps the payload in a complete RFC 5424 syslog message.

Syslog Timestamp

For partial_syslog and rfc5424, the Syslog TIMESTAMP represents the original event time from createdAt, not the time Rublon Log Sync exported the record. The timestamp is normalized to UTC and formatted as RFC 3339 with millisecond precision.

If createdAt is missing or invalid, the Syslog TIMESTAMP is set to - (NILVALUE). The record is still delivered.

This behavior does not change the JSON payload, the bare envelope, or the CEF rt field. CEF rt continues to use UTC epoch milliseconds and is omitted when createdAt is missing or invalid.

Syslog PRI and Severity

For Rublon Admin API records that are JSON objects, JSON and CEF output use the same event classification to determine Syslog severity. The same record therefore produces the same Syslog severity and PRI in partial_syslog and rfc5424 envelopes, regardless of the selected payload format.

For Audit Logs, Authentication Logs, and Phone Logs, a missing, empty, non-text, or unrecognized event or status uses the fallback classification: CEF severity 4 and Syslog severity 4 (Warning). With facility local0, this produces PRI <132>.

Activity Logs always use Syslog severity 5 (Notice), regardless of their event type or payload format. With facility local0, this produces PRI <133>. Their CEF severity remains event-dependent, as described in Activity Severity.

The bare envelope has no Syslog header or PRI.

Configuration Changes and Checkpoints

Checkpoint files are associated with a synchronization job identity.

Changing source-identifying settings can prevent an existing checkpoint from being reused. These settings include:

• synchronization job id
• rublon.api_server
• rublon_endpoints
• from_datetime

If a checkpoint is no longer compatible, restore the previous configuration or stop the application and remove the checkpoint for the affected job.

Removing a checkpoint causes the job to start again from from_datetime. If from_datetime is not configured, the job can retrieve records from the maximum lookback window allowed by the endpoint. This can cause records that were already sent to the SIEM target to be sent again.

Running Rublon Log Sync

Continuous Synchronization

Continuous synchronization is the normal operating mode for service deployments.

Start the service:

sudo systemctl start rublon-log-sync

In this mode, each synchronization job runs repeatedly according to its configured interval.

Enable automatic startup at boot:

sudo systemctl enable rublon-log-sync

One-Shot Synchronization

Use one-shot mode to run all configured synchronization jobs once and then exit. It is useful for verifying configuration and end-to-end log delivery or for performing a deliberate one-time historical synchronization within the endpoint lookback limits. One-shot mode is not a dry run: it sends records to the configured SIEM targets and saves checkpoints when checkpointing is enabled. If a compatible checkpoint exists, synchronization resumes from that checkpoint instead of from_datetime.

Stop the service before manually running the same configuration:

sudo systemctl stop rublon-log-sync

Run one synchronization cycle:

sudo -u rublon-log-sync \
  /opt/rublon-log-sync/bin/rublon-log-sync \
  --config-file-path /etc/rublon-log-sync/config.yaml \
  --logs-dir-path /var/log/rublon-log-sync \
  --checkpoints-dir-path /var/lib/rublon-log-sync/checkpoints \
  --once

In one-shot mode, Rublon Log Sync:

1. runs every configured synchronization job once;
2. retrieves available records;
3. sends the records to the configured SIEM targets;
4. saves checkpoints when enabled;
5. exits.

Verify Log Delivery to Your SIEM

After running synchronization, verify that the exported records are available in your SIEM:

1. Open your SIEM’s log search and select the input, stream, or index configured to receive Rublon MFA logs.
2. Set the search time range to include the timestamps of the synchronized events.
3. Confirm that Rublon MFA records appear and open a record to check its contents. If you configured field extraction, verify that the expected fields are populated.

The example below shows a Rublon MFA Authentication Log received by Graylog in CEF format, with fields such as the authentication result, application name, and application type.

Configuration Source

You can load the configuration:

• from a specific YAML file using --config-file-path;
• from a directory containing config.yaml or config.yml using --config-dir-path.

Directory mode must contain exactly one supported configuration file. If both config.yaml and config.yml exist in the selected directory, the application will not start.

Runtime Command-Line Options

The following options apply when you start the Rublon Log Sync executable manually or customize the command used by the systemd service. They are not installation options.

Option	Description
--config-file-path PATH	Loads a specific YAML configuration file. Cannot be used together with --config-dir-path.
--config-dir-path PATH	Loads config.yaml or config.yml from a directory. Cannot be used together with --config-file-path.
--logs-dir-path PATH	Sets the directory for application log files. The Linux service uses /var/log/rublon-log-sync.
--checkpoints-dir-path PATH	Sets the directory for checkpoint files. The Linux service uses /var/lib/rublon-log-sync/checkpoints.
--once	Runs one synchronization cycle and exits. Without this option, the application runs continuously.

Managing the Service

Check the service status:

systemctl status rublon-log-sync

Start the service:

sudo systemctl start rublon-log-sync

Stop the service:

sudo systemctl stop rublon-log-sync

Restart the service:

sudo systemctl restart rublon-log-sync

Enable automatic startup:

sudo systemctl enable rublon-log-sync

Disable automatic startup:

sudo systemctl disable rublon-log-sync

Updating Rublon Log Sync

This procedure applies to an official Rublon Log Sync 1.0.0 installation in the standard Linux locations and upgrades it to 1.1.0. Non-standard or partially installed environments require an adapted procedure.

Schedule a maintenance window. Run the commands in order and stop if any command fails unexpectedly.

1. Prepare for the Upgrade

Download version 1.1.0 from Rublon Downloads, verify its SHA-256 checksum against the published value, and extract the package. Run the installer in Step 3 from the extracted directory.

Review Before Updating, including the configuration limits and SIEM mapping changes:

• interval must be an integer of at least 60; the default is 60.
• per_page must be an integer from 15 to 1000; the default is 100.

Correct incompatible values before creating the backup. No new mandatory configuration fields are required.

Preserve checkpoint compatibility: Keep existing job IDs, rublon.api_server, from_datetime, endpoint types, and endpoint filters unchanged. Versions 1.0.0 and 1.1.0 use the same checkpoint format for unchanged jobs. Add Activity Logs only after verifying the upgrade, as a separate job with a new ID.

Record the current service states and inspect the effective unit:

systemctl is-active rublon-log-sync
systemctl is-enabled rublon-log-sync
systemctl cat rublon-log-sync

Identify any customizations to the main unit and confirm that referenced environment files exist and have the required permissions. The installer replaces the main unit, so required customizations must be preserved as drop-ins. Review the output locally; it may contain secrets.

Do not use --once as a validation-only test: it sends records and updates checkpoints.

2. Stop the Service and Back Up the Installation

Stop the service and confirm that its state is inactive before copying files:

sudo systemctl stop rublon-log-sync
systemctl is-active rublon-log-sync

Create a root-only backup directory:

sudo install -d -o root -g root -m 0700 /var/backups/rublon-log-sync
sudo mktemp -d /var/backups/rublon-log-sync/1.0.0-before-1.1.0-XXXXXXXX

Record the path printed by mktemp. Replace <backup-directory> below with that exact path. Keep the backup restricted to root because it contains configuration and potentially credentials.

Run each copy command separately. Do not continue if a copy fails:

sudo cp -a /opt/rublon-log-sync "<backup-directory>/opt-rublon-log-sync"
sudo cp -a /etc/rublon-log-sync "<backup-directory>/etc-rublon-log-sync"
sudo cp -a /var/lib/rublon-log-sync "<backup-directory>/var-lib-rublon-log-sync"
sudo cp -a /etc/systemd/system/rublon-log-sync.service \
  "<backup-directory>/rublon-log-sync.service"

If /etc/systemd/system/rublon-log-sync.service.d exists, also back it up:

sudo cp -a /etc/systemd/system/rublon-log-sync.service.d \
  "<backup-directory>/rublon-log-sync.service.d"

Confirm that all required copies exist before installing:

sudo ls -la "<backup-directory>"

3. Install Version 1.1.0

From the extracted 1.1.0 package directory, run:

sudo bash scripts/install-linux.sh --artifact bin/rublon-log-sync

The installer replaces the application, bundled documentation, example configuration, and main systemd unit. It preserves the production configuration, environment file, drop-ins, checkpoints, and application logs. It does not start the service or change its enabled state.

Confirm that the production configuration and environment file retain their intended contents and permissions. Compare the configuration with the new example only to identify intentional changes.

Inspect the installed unit:

systemctl cat rublon-log-sync

Confirm that RestartPreventExitStatus=78 is present and existing drop-ins still reference the correct environment file. Recreate any required customizations from the backed-up main unit using:

sudo systemctl edit rublon-log-sync

Do not restore the old main unit during the upgrade, as this would remove the new restart-prevention setting. After changing drop-ins, reload systemd:

sudo systemctl daemon-reload

4. Restore the Service State and Verify

If the service was active before the upgrade, start it:

sudo systemctl start rublon-log-sync

If it was intentionally inactive, leave it stopped. Preserve its previous enabled or disabled state; do not enable automatic startup unless intended.

Check the states against those recorded before the upgrade:

systemctl is-active rublon-log-sync
systemctl is-enabled rublon-log-sync
systemctl status rublon-log-sync

If the service was started, check its logs and version:

sudo journalctl -u rublon-log-sync -b
sudo grep -F "Rublon Log Sync started: version=1.1.0" \
  /var/log/rublon-log-sync/rublon-log-sync.log

Confirm that the startup entry is from after the upgrade, no configuration or checkpoint errors occur, and existing jobs fetch and send logs. In the SIEM, verify representative events, including timestamps, PRI/severity, and CEF identifiers affected by the release.

If the service remains intentionally stopped, defer delivery verification until its next planned start.

Rollback to Version 1.0.0

Use the backup created above. Restore the application and service configuration together; replacing only the binary is insufficient. Stop if any restoration command fails.

1. Stop the service and confirm inactive:

sudo systemctl stop rublon-log-sync
systemctl is-active rublon-log-sync

Confirm that <backup-directory> points to the recorded backup. Create a suffix for preserving the current files, and keep the same shell session open:

RLS_ROLLBACK_SUFFIX="$(date +%Y%m%d-%H%M%S)"

2. Preserve the current application and restore version 1.0.0:

sudo mv /opt/rublon-log-sync \
  "/opt/rublon-log-sync.failed-1.1.0-$RLS_ROLLBACK_SUFFIX"
sudo cp -a "<backup-directory>/opt-rublon-log-sync" /opt/rublon-log-sync
sudo cp -a "<backup-directory>/etc-rublon-log-sync/config.example.yaml" \
  /etc/rublon-log-sync/config.example.yaml
sudo cp -a "<backup-directory>/rublon-log-sync.service" \
  /etc/systemd/system/rublon-log-sync.service

If the current drop-in directory exists, preserve it:

sudo mv /etc/systemd/system/rublon-log-sync.service.d \
  "/etc/systemd/system/rublon-log-sync.service.d.failed-1.1.0-$RLS_ROLLBACK_SUFFIX"

If the backup contains a drop-in directory, restore it; otherwise, leave the path absent:

sudo cp -a "<backup-directory>/rublon-log-sync.service.d" \
  /etc/systemd/system/rublon-log-sync.service.d

3. Restore production configuration only if needed.

Leave config.yaml and the environment file unchanged if they were not modified after the backup and remain compatible with 1.0.0. Otherwise, restore only the files that require recovery:

sudo cp -a "<backup-directory>/etc-rublon-log-sync/config.yaml" \
  /etc/rublon-log-sync/config.yaml

sudo cp -a "<backup-directory>/etc-rublon-log-sync/rublon-log-sync.env" \
  /etc/rublon-log-sync/rublon-log-sync.env

Before starting 1.0.0, ensure that the configuration contains no activity endpoint.

4. Decide whether to restore checkpoints.

Do not restore them automatically. For unchanged jobs, the latest checkpoints remain compatible and are usually preferable. Restoring older checkpoints after 1.1.0 has synchronized records can resend those records.

Only if restoring the pre-upgrade checkpoints is necessary and the duplicate-delivery risk has been assessed, run:

sudo mv /var/lib/rublon-log-sync/checkpoints \
  "/var/lib/rublon-log-sync/checkpoints.failed-1.1.0-$RLS_ROLLBACK_SUFFIX"
sudo cp -a "<backup-directory>/var-lib-rublon-log-sync/checkpoints" \
  /var/lib/rublon-log-sync/checkpoints

5. Reload systemd and restore the previous service states.

sudo systemctl daemon-reload
systemctl cat rublon-log-sync

Confirm that the restored executable exists, has execute permission, and the effective unit references the expected paths. Restore the recorded enabled state using sudo systemctl enable rublon-log-sync or sudo systemctl disable rublon-log-sync, as appropriate.

Start the service only if it was active before the upgrade:

sudo systemctl start rublon-log-sync

Verify the recorded service states:

systemctl is-active rublon-log-sync
systemctl is-enabled rublon-log-sync

If started, confirm a new version 1.0.0 startup entry, review application logs, and verify SIEM delivery:

sudo grep -F "Rublon Log Sync started: version=1.0.0" \
  /var/log/rublon-log-sync/rublon-log-sync.log
sudo journalctl -u rublon-log-sync -b

Keep the backup and preserved 1.1.0 files until rollback verification succeeds. If the service was intentionally inactive, leave it stopped and defer delivery verification until its next planned start.

Uninstalling Rublon Log Sync

The following steps remove the application and its systemd service while preserving configuration, checkpoints, logs, custom service overrides, and the dedicated system user and group.

1. Stop the service and disable automatic startup:

sudo systemctl disable --now rublon-log-sync

2. Remove the service unit and application files:

sudo rm -f /etc/systemd/system/rublon-log-sync.service

sudo rm -rf /opt/rublon-log-sync

3. Reload the systemd manager configuration:

sudo systemctl daemon-reload

Optional: Remove Configuration and Stored Data

To also remove configuration files, stored credentials, checkpoints, application log files, and custom systemd service overrides, run:

sudo rm -rf /etc/rublon-log-sync
sudo rm -rf /var/lib/rublon-log-sync
sudo rm -rf /var/log/rublon-log-sync
sudo rm -rf /etc/systemd/system/rublon-log-sync.service.d
sudo systemctl daemon-reload

Back up any files you want to retain before running these commands. Deleting checkpoints removes saved synchronization progress. If you reinstall Rublon Log Sync without restoring compatible checkpoints, previously exported records may be sent to your SIEM again.

These commands do not remove records already delivered to your SIEM or entries stored in the system journal.

Application Logs

Rublon Log Sync operational logs are separate from the Rublon MFA records forwarded to the SIEM target.

Application logs can include:

• startup and shutdown events
• selected synchronization mode
• synchronization job cycle status
• produced and consumed batch counts
• SIEM delivery counts
• checkpoint saves
• Admin API retry and failure information
• configuration and runtime errors

The Linux service writes the main application log to:

/var/log/rublon-log-sync/rublon-log-sync.log

Rublon Log Sync creates daily archived log files in the same directory. By default, it retains seven archived daily files in addition to the current log file. Change the retention using log.log_files_count.

Warnings and errors are also sent to stderr and collected by journald.

View service diagnostics:

journalctl -u rublon-log-sync

Follow diagnostics in real time:

journalctl -u rublon-log-sync -f

View diagnostics from the current boot:

journalctl -u rublon-log-sync -b

Treat application logs as sensitive operational data. They should not contain Rublon Admin API credentials, but they can include job identifiers, endpoint types, hostnames, ports, retry information, and error details.

Checkpoints

Checkpointing is enabled by default for every synchronization job.

Checkpoint files store synchronization progress and allow Rublon Log Sync to resume from the last saved position during a later run.

The Linux service stores checkpoints in:

/var/lib/rublon-log-sync/checkpoints

CEF Mapping

When target.format is set to cef, Rublon Log Sync converts each Admin API record to a CEF version 1 event.

The following sections describe the endpoint-specific mappings.

The mappings cover Audit Logs, Authentication Logs, Phone Logs, and Activity Logs. Event classification is shared with JSON output when determining Syslog severity for object records. Activity Logs have a Syslog-specific override: they always use Notice severity in the Syslog envelope, while their CEF severity follows the Activity Severity rules.

Common Mapping Rules

A source value is treated as missing when:

• the field is not present
• the value is null
• the value is an empty string after leading and trailing whitespace is removed

Optional CEF extension fields are omitted when their source value is missing.

A label such as cs1Label is included only when its paired value field, such as cs1, is included.

• Text values are converted to strings.
• Numeric CEF fields are emitted as integers.
• Objects and arrays are serialized as compact JSON with deterministic key ordering when the endpoint mapping explicitly allows it.
• Nested objects are not automatically flattened.

Timestamp Mapping

The createdAt value is mapped to the CEF rt field as UTC epoch milliseconds.

Example:

2023-07-26T08:40:03.365Z -> 1690360803365

If createdAt is missing or cannot be parsed, rt is omitted.

Common Extension Fields

CEF Extension	Source	Rule
externalId	id	Omitted when missing.
rt	createdAt	UTC epoch milliseconds. Omitted when missing or invalid.
cat	endpoint type	Always rublon.<endpoint>.
act	endpoint-specific action	event for Audit Logs and Activity Logs; status for Authentication Logs and Phone Logs. Omitted when missing.

Audit Logs

CEF Event Fields

CEF Event Field	Mapping
Event Class ID	Uses event when present. Otherwise, uses audit.
Name	Uses activity when present. Otherwise, uses event. If both are missing, uses Rublon audit event.
Severity	Determined according to the Audit Severity table.

Audit Log Extension Fields

Fields are emitted in the following order:

Order	CEF Extension	Source	Rule
1	externalId	id	Omitted when missing.
2	rt	createdAt	UTC epoch milliseconds.
3	cat	endpoint type	Always rublon.audit.
4	act	event	Omitted when missing.
5	suser	actor.email, actor.name, actor.id	Uses the first available value in the listed order.
6	src	location	For an array, uses the first non-empty ip found in an object. A location object is also accepted. Omitted when unavailable.
7	suid	actor.id	Included only when actor.type is administrator and the identifier is non-empty.
8	flexString1	actor.id	Included only when actor.type is application and the identifier is non-empty.
9	flexString1Label	constant	applicationId, included only with flexString1.
10	cs2	actor.type	Omitted when missing.
11	cs2Label	constant	actorType, included only with cs2.
12	cs3	actor.role	Omitted when missing.
13	cs3Label	constant	actorRole, included only with cs3.
14	cs4	affected	Converted to text. Omitted when missing.
15	cs4Label	constant	affected, included only with cs4.
16	cs5	location	Serializes a non-empty array or object as compact JSON. Omitted when missing, empty, or neither an array nor an object.
17	cs5Label	constant	location, included only with cs5.
18	cs6	details, changes	Uses details when present; otherwise, uses changes. Scalar values are converted to text; objects and arrays are serialized as compact JSON.
19	cs6Label	constant	details or changes, matching the source used for cs6.

Audit Severity

Severity is based on the event field. Leading and trailing whitespace is removed before classification, and matching is case-sensitive. A missing or null value, empty or whitespace-only text, a non-text value, or an unrecognized event uses fallback severity 4.

Rules are evaluated in the following order:

1. Exact matches
2. Prefix or suffix matches
3. Fallback severity 4

Severity	Rule
6	Exact Administrator.Authentication.Fail
6	Exact User.DirectorySync.Fail
5	Event ends with .Delete
5	Event ends with .Password.Reset
5	Event ends with .Password.Update
5	Exact System.Tenant.UpdateSettings
5	Exact System.Admin.SignInSettings.Update
5	Exact System.Data.Import.Users
5	Exact User.DirectorySync.Configuration.Delete
5	Exact System.Billing.Subscription.Cancel
4	Exact Administrator.Authentication.Bypass
4	Exact Administrator.Authentication.Cancel
4	Event ends with .Create
4	Event ends with .Update
4	Event ends with .Assign
4	Event ends with .Unassign
4	Event ends with .Remove
4	Event ends with .Add
4	Event ends with .MovedToTop
4	Event starts with System.Data.Export.
4	Exact User.DirectorySync.Start
4	Exact User.DirectorySync.Connection.Create
4	Exact User.DirectorySync.Configuration.Create
4	Exact User.DirectorySync.Configuration.Update
3	Exact Administrator.Authentication.Success
3	Event ends with .Complete
3	Event ends with .Sent
3	Event ends with .Made
3	Event starts with System.Billing.InvoiceDetails.
3	Exact System.Billing.PhoneCredits.Add
3	Exact System.Billing.Subscription.Activate
3	Event starts with System.Communication.
4	Missing, empty, non-text, or unknown event

Activity Logs

The following mapping applies to records retrieved from /api/admin/logs/activity using type: activity.

CEF Event Fields

CEF Event Field	Mapping
Event Class ID	Uses the event field when present; otherwise, uses the activity field. If both fields are missing, uses the literal value activity.
Name	Uses the activity field when present; otherwise, uses the event field. If both fields are missing, uses Rublon activity event.
Severity	Determined according to the Activity Severity table.

Activity Log Extension Fields

Fields are emitted in the following order:

Order	CEF Extension	Source	Rule
1	externalId	id	Omitted when missing.
2	rt	createdAt	UTC epoch milliseconds.
3	cat	endpoint type	Always rublon.activity.
4	act	event	Omitted when missing.
5	suser	actor.email, actor.name, actor.id	Uses the first available value in the listed order.
6	suid	actor.id	Omitted when missing.
7	src	location	For an array, uses the first non-empty ip found in an object. A location object is also accepted. Omitted when unavailable.
8	cs2	actor.type	Omitted when missing.
9	cs2Label	constant	actorType, included only with cs2.
10	cs3	actor.role	Omitted when missing.
11	cs3Label	constant	actorRole, included only with cs3.
12	cs4	source	Omitted when missing.
13	cs4Label	constant	source, included only with cs4.
14	cs5	location	Serializes a non-empty array or object as compact JSON. Omitted when missing, empty, or neither an array nor an object.
15	cs5Label	constant	location, included only with cs5.
16	cs6	changes	Scalar values are converted to text; objects and arrays are serialized as compact JSON. Omitted when missing.
17	cs6Label	constant	changes, included only with cs6.

The fields cs1, cs1Label, flexString1, and flexString1Label are not used for Activity Logs.

Activity Severity

Severity is based on the event field. Leading and trailing whitespace is removed before classification, and matching is case-sensitive. Activity Logs have their own rules; Audit-specific exact matches and prefixes do not apply.

Severity	Rule
5	Event ends with .Delete
4	Event ends with .Create
4	Event ends with .Update
4	Event ends with .Activate
4	Event ends with .Deactivate
4	Missing, empty, non-text, or unknown event

These values determine CEF severity. When a Syslog envelope is selected, Activity Logs always use Syslog severity 5 (Notice), regardless of the CEF severity or payload format.

Authentication Logs

For severity calculation, the status value is trimmed and converted to lowercase. The original trimmed value is used in the Event Class ID, Name, and act fields.

CEF Event Fields

CEF Event Field	Mapping
Event Class ID	Uses authentication.<status> when status is present. Otherwise, uses authentication.unknown.
Name	Uses Rublon authentication <status> when status is present. Otherwise, uses Rublon authentication unknown.
Severity	Determined according to the Authentication Severity table.

Authentication Log Extension Fields

Order	CEF Extension	Source	Rule
1	externalId	id	Omitted when missing.
2	rt	createdAt	UTC epoch milliseconds.
3	cat	endpoint type	Always rublon.authentication.
4	act	status	Omitted when missing.
5	suser	user.email, user.username, user.loginUsed	Uses the first available value in the listed order.
6	suid	user.id	Stable Rublon user identifier. Omitted when missing.
7	src	device.location.ip	Omitted when unavailable.
8	request	application.url	Omitted when missing.
9	requestClientApplication	device.userAgent	Omitted when missing.
10	flexString1	application.id	Stable Rublon application identifier. Omitted when missing.
11	flexString1Label	constant	applicationId, included only with flexString1.
12	cs1	method	Omitted when missing.
13	cs1Label	constant	method, included only with cs1.
14	cs2	step	Omitted when missing.
15	cs2Label	constant	step, included only with cs2.
16	cs3	application.name	Omitted when missing.
17	cs3Label	constant	applicationName, included only with cs3.
18	cs4	application.type	Omitted when missing.
19	cs4Label	constant	applicationType, included only with cs4.
20	cs5	device.osName	Omitted when missing.
21	cs5Label	constant	osName, included only with cs5.
22	cs6	device.browser	Omitted when missing.
23	cs6Label	constant	browser, included only with cs6.

Authentication Severity

Status	Severity
granted	3
bypassed	4
denied	6
Missing, empty, non-text, or unknown	4

Phone Logs

The context, method, and status values are trimmed before the Event Class ID and Name are created. A missing component is replaced with unknown.

CEF Event Fields

CEF Event Field	Mapping
Event Class ID	phone.<context>.<method>.<status>, with unknown used for missing components.
Name	Rublon phone <context> <method> <status>, with unknown used for missing components.
Severity	Determined according to the Phone Severity table.

Phone Log Extension Fields

Order	CEF Extension	Source	Rule
1	externalId	id	Omitted when missing.
2	rt	createdAt	UTC epoch milliseconds.
3	cat	endpoint type	Always rublon.phone.
4	act	status	Omitted when missing.
5	suser	user.email, user.username, user.name	Uses the first available value in the listed order.
6	suid	user.id	Stable Rublon user identifier. Omitted when missing.
7	flexString1	application.id	Stable Rublon application identifier. Omitted when missing.
8	flexString1Label	constant	applicationId, included only with flexString1.
9	cs1	context	Omitted when missing.
10	cs1Label	constant	context, included only with cs1.
11	cs2	method	Omitted when missing.
12	cs2Label	constant	method, included only with cs2.
13	cs3	number	Omitted when missing. The phone number is not mapped to duser.
14	cs3Label	constant	phoneNumber, included only with cs3.
15	cs4	application.name	Omitted when missing.
16	cs4Label	constant	applicationName, included only with cs4.
17	cs5	application.type	Omitted when missing.
18	cs5Label	constant	applicationType, included only with cs5.
19	cs6	user.status	Omitted when missing.
20	cs6Label	constant	userStatus, included only with cs6.
21	cn1	credits	Included only when the value is an integer or a string containing an integer.
22	cn1Label	constant	credits, included only with cn1.

Phone Severity

Status	Severity
success	3
sent	3
completed	3
accepted	3
delivered	3
failed	6
error	6
denied	6
Missing, empty, non-text, or unknown	4

Security Best Practices

• Run the service as the dedicated, unprivileged rublon-log-sync user.
• Store application files under /opt/rublon-log-sync.
• Store configuration under /etc/rublon-log-sync.
• Store checkpoint state under /var/lib/rublon-log-sync.
• Store operational logs under /var/log/rublon-log-sync.
• Prefer environment variables instead of storing Admin API credentials directly in YAML.
• Restrict read access to configuration and environment files that contain credentials.
• Treat credentials included in global.proxy_url as secrets.
• Remove credentials before sharing configuration snippets, screenshots, diagnostics, or support bundles.
• Protect the network path between Rublon Log Sync and the SIEM target according to your organization’s security requirements.
• Do not delete checkpoints unless you intentionally want to reset synchronization progress.
• Use NoNewPrivileges=true and an empty CapabilityBoundingSet= in the service definition when the application does not require elevated Linux capabilities.

Troubleshooting

Check the Service Status

systemctl status rublon-log-sync

Check Application Logs

/var/log/rublon-log-sync/rublon-log-sync.log

Temporarily enable additional diagnostic information when required:

log:
  debug: true

Restart the service after changing the configuration:

sudo systemctl restart rublon-log-sync

Do not leave debug logging enabled longer than necessary because it can increase the amount of operational information stored in log files.

Check systemd Diagnostics

journalctl -u rublon-log-sync -b

Follow new messages:

journalctl -u rublon-log-sync -f

Organization Plan Restriction (Exit Code 78)

If the Rublon Admin API reports that the organization’s plan does not permit access to logs, Rublon Log Sync stops all synchronization jobs without retrying and exits with code 78. The installed systemd service does not restart automatically after this error.

Check the application log for details and restore Admin API log access for the organization. Then follow the instructions in Reset a Failed Service below to resume synchronization.

Reset a Failed Service

If the service fails repeatedly, systemd can stop restarting it because of start-limit protection.

After correcting the cause, reset the failure state and start the service:

sudo systemctl reset-failed rublon-log-sync
sudo systemctl start rublon-log-sync

Common Startup Issues

If Rublon Log Sync does not start, verify that:

• the selected configuration file or directory exists
• the YAML file is valid and not empty
• exactly one of config.yaml or config.yml exists when directory mode is used
• the Rublon Admin API credentials are present
• required environment variables exist and are not empty when secret_source is set to env
• rublon.api_server is an HTTPS base URL without an endpoint path, query string, username, or password
• every synchronization job has a unique, non-empty id
• every job contains at least one supported endpoint
• endpoint types are not duplicated within a job
• every configured interval is an integer of at least 60
• every configured per_page is an integer from 15 to 1000
• from_datetime is valid, is not in the future, and falls within the applicable API lookback limit
• the SIEM target hostname, port, protocol, payload format, and envelope are valid
• the service user can read the configuration
• the service user can write to /var/lib/rublon-log-sync and /var/log/rublon-log-sync
• the executable exists and has execute permissions
• the Linux server can reach the Rublon API server and SIEM target

Duplicate Records

If records that were already delivered are sent again, check whether:

• a checkpoint file was deleted;
• the checkpoint directory was removed;
• the synchronization job id changed;
• rublon.api_server, rublon_endpoints, or from_datetime changed;
• the application started with a different checkpoints directory.

Restore the previous source-identifying configuration to reuse a compatible checkpoint. Otherwise, accept that the affected job will start without the previous saved position.

No Records Arrive at the SIEM Target

Verify that:

• the target hostname and TCP port are correct;
• the target is listening for TCP connections;
• the firewall allows the connection;
• the target expects the selected JSON or CEF payload;
• the target accepts the selected envelope;
• the configured endpoints contain records within the synchronization time range;
• the application log does not report API or delivery errors.

If other log types arrive but recent Phone Logs are missing, the records may still be awaiting telecommunications provider updates. Allow time for the records to become available and for another synchronization cycle to run. If you used one-shot mode, run it again after the records become available. See Phone Log Availability and Event Ordering.

I have a different issue

If you continue to experience issues, contact Rublon Support. Include a detailed issue description and relevant diagnostic logs, but remove all credentials and other sensitive information before sending them.

Related Posts

• Rublon Log Sync – Release Notes
• Rublon Admin API
• Rublon Admin API Endpoints
• Rublon MFA Logs
• Rublon Downloads