Skip to main content

Security & Data Protection

This page summarizes how the Connector and the OVA appliance are secured, what data they retain locally, and how to decommission an appliance.

Network posture

The Connector makes outbound-only connections — see Network Requirements for the full destination list. Nothing needs to connect to it. The OVA appliance additionally runs a host firewall with a default-deny inbound policy and ships with SSH disabled, so it presents no listening network service at all.

Transport security

Every connection the Connector makes — to FireMon Connect and to the update service — uses TLS with full hostname and certificate validation. There is no option to disable certificate validation on the FireMon-facing connections. (Connecting to an on-prem integration with a self-signed certificate, such as a lab Panorama, is a separate, explicit, opt-in setting on that integration — see Integrations.)

Log forwarding

The Connector writes structured logs locally (see Installation — where logs live) and also forwards entries at INFO level and above to FireMon, over the same outbound TLS connection to api.prod.firemon.cloud it uses for job traffic. This lets FireMon Support diagnose a Connector without asking you to collect files off the appliance.

Forwarded entries contain operational data: hostnames, IP addresses, and the names of objects the Connector reads or writes — Connect Groups, Panorama device groups and Dynamic Address Groups, NSX Groups, Infoblox networks. The Connector does not log its API key, and does not log the credentials you provide for on-prem integrations.

Forwarding is on by default and has no separate off switch. Raising the Connector's log level — FIREMON_LOG_LEVEL=WARN, or logLevel in its config file — reduces what is written locally and therefore what is forwarded.

Pairing and credentials

  • Pairing uses a short-lived (24-hour), single-use registration code you generate in Connect. The code is consumed the moment it's used, so it can't be replayed.
  • Once paired, the Connector authenticates with an API key issued by FireMon. The key is written to a local credentials file that is readable only by the account running the Connector (0600 permissions on Linux/macOS), and is not written to logs.
  • Removing the Connector from Settings > Connectors in Connect immediately revokes its API key — this is the authoritative way to cut off a Connector's access.

The OVA appliance

The appliance is a minimal, hardened Ubuntu Linux VM built specifically to run the Connector:

  • No default passwords, SSH locked down. The base image ships with no default credentials, and SSH is disabled — there's no network-facing login surface.
  • Runs as a restricted, non-root service account with a locked-down filesystem and Linux capabilities dropped to the minimum the Connector needs.
  • Security updates apply automatically, including a maintenance-window reboot for updates that require one, so the OS stays current without manual intervention.
  • Console access is equivalent to root/physical access, the same as most virtual appliances. Because the appliance has no default password and no network login service, the console is its only administrative path — so restrict who can open it the same way you'd restrict physical access to a device. In vSphere, scope the Console Interaction privilege to the administrators who should have it. See Deploying the OVA appliance.
  • Every self-update is cryptographically signed and verified before it's installed — see Updates.

What the appliance stores locally

Job and inventory data (from Panorama, Infoblox, etc.) is processed in memory and is never written to disk. What does persist:

ContentsSensitive?
API key, Connector ID, client IDYes — API key
Environment, version, and log/update settingsNo secrets
Rotated local logs (~50 MB cap)Operational data (IPs, object names) — no credentials

The credentials file is restricted to the service account that runs the Connector (0600 on Linux/macOS) and is not additionally encrypted at the application level.

For sensitive deployments, enable vSphere VM or datastore encryption on the Connector VM. This protects the disk — and every snapshot or backup taken from it — against theft of the underlying storage, which is a more effective control for a VM appliance than application-level encryption (a key stored on the same disk protects little against someone who already has the disk).

Snapshots and backups

A vSphere snapshot or backup of the Connector VM captures the API key and local logs. Treat Connector snapshots and backups as sensitive, access-restricted material — the same as the running appliance. If you can't use datastore encryption and snapshots are unavoidable, decommission the appliance (below) — which revokes the API key server-side — before archiving or exporting a snapshot.

Decommissioning an appliance

Revoking the API key server-side is the control that actually matters. Once revoked, a leaked disk, snapshot, or backup is worthless — the key no longer authenticates anything. Follow all three steps for a clean decommission:

  1. Revoke server-side (required). In FireMon Connect, open Settings > Connectors, find the Connector, and remove it. This deletes its API key immediately.

  2. Wipe local state (defense-in-depth). On the appliance, stop the service and run the built-in decommission command:

    sudo systemctl stop firemon-connector.service
    sudo -u firemon-connector /usr/local/bin/firemon-connector --decommission

    The command lists what it's about to remove — the credentials file, its quarantined credentials.json.invalid sibling if one exists, and the log directory — and then requires you to type the word decommission to proceed; anything else cancels. Add --yes to skip the prompt for scripted use. It does not revoke the Connector server-side — that's step 1.

  3. Delete the VM, including its datastore files and any snapshots or backups taken from it.

Steps 1 and 3 are sufficient on their own — a deleted VM whose key has been revoked leaks nothing usable. Step 2 covers the window between revocation and disk deletion, and any disk image that outlives the VM.