For security and change teams
Security and deployment safety
What we install and with what privileges, how it is built not to break a host, what leaves the network, where data lives, how we build and ship, and how to deploy and remove LinuxGuard safely.
- Read-only collectionOnly a response action someone has approved alters a server.
- Fails openIf a rule is missing or a lookup fails, the sensor allows the action rather than blocking it.
- Outbound 443 onlyServers connect outwards over HTTPS on port 443, with no inbound ports from the internet.
- EU-hostedCustomer data, backups included, is hosted in the EU and encrypted in transit and at rest.
- Signed packagesAgent packages are signed and installed from a signed repository.
- Removable any timeUnenrol the server, then remove the package with the package manager.
What we install, and with what privileges
Signed packages or containers
LinuxGuard is installed from signed packages for Debian and Ubuntu, the Red Hat family, SUSE and Alpine, or run as a container image on containerised estates.
What installation adds
Installing the agent adds a signed package repository, a dedicated service account, the agent itself and a monitoring sensor. On servers that support full monitoring it also enables an optional security setting in the boot configuration that takes effect at the next reboot. Nothing in the installation blocks existing security patching.
Runs as service account
Installed from packages, the agent runs as that service account, not as root. Work that genuinely needs root, such as an approved package fix or an approved containment action, is done by separate small helpers. They accept only a short, fixed list of operations, never a script or a free-form command. A package fix carries a signed instruction that the helper verifies before it acts.
Read-only collection
Collection is read-only and kept apart from anything that makes a change. Apart from installation and automatic updates, which can be switched off, the only thing that alters a server is a response action someone has approved.
Container requirements documented
For container deployments, the documentation lists exactly what the container needs.
In the documentation: Agent · Container deployment
Built not to break a host
Fails open
The monitoring sensor fails open. If a rule is missing, a lookup fails or a server does not support a feature, it allows the action rather than blocking it.
Core programs never blocked
Core system programs, including shells, SSH, the system manager and package managers, and the paths a server needs to boot can never be blocked, whatever a rule says.
Starts in log-only mode
The sensor starts in log-only mode. Blocking begins only after an administrator types a confirmation in the console, and there is a kill switch, with several independent levels, for the day one is needed.
Containment needs approval
Containment needs approval. Locking an account, revoking sudo and disabling an SSH key all reverse automatically after four hours unless confirmed. Ending a session is immediate and cannot be reversed. The affected user's terminal is warned first, and every action is recorded in the server's system log.
Falls back, carries on
On a server that cannot run the sensor, monitoring falls back to a simpler mode and the rest of the agent carries on unaffected.
What leaves the network, and how
Outbound HTTPS only
Servers connect outwards only, over HTTPS on port 443, to LinuxGuard's service addresses, listed in the documentation. They need no inbound ports from the internet; a relay, if used, accepts connections only from inside the customer network.
Mutually authenticated connection
The connection is mutually authenticated and encrypted, and each server has its own credentials.
Isolated segments via relay
Servers in isolated segments reach LinuxGuard through that relay: one server in the customer network with outbound access, which carries the monitoring traffic for the rest. Isolated servers fetch packages and updates through an existing HTTP proxy or an internal mirror.
In the documentation: Network requirements · Relay for isolated networks
Where data lives, and who can see it
Hosted in the EU
Customer data, backups included, is hosted in the EU: in Dublin, with disaster recovery from Frankfurt. It is encrypted in transit and at rest.
UK or EU/EEA personnel
All engineers, administrators and support personnel with access to the production environment are legal residents of the UK or EU/EEA.
Kept separate per customer
Each customer's data is kept separate at three independent layers.
Sub-processors in the DPA
Our sub-processors, and the measures behind all of this, are set out in the data processing agreement.
How we build and ship
Checks gate every release
Every service passes automated tests, dependency vulnerability scans and code analysis before release. A failed check blocks the release.
No secrets in code
No secrets are kept in source code; they live in a managed secrets store. Infrastructure is defined as code, and changes go through a staging environment before production.
Signed packages
Agent packages are signed, and servers install them from a signed repository.
Controlled updates
Updates come on two channels, stable and pre-release, and stable is the default. Servers check once a day at a random time within a four-hour window, so a fleet never updates all at once. Automatic updates can be switched off, so that every update goes through an existing change process. A server can be updated by hand with its package manager at any time, and container deployments can pin a version tag.
In the documentation: Updates and uninstallation
Deploying safely
Preflight check first
The agent's preflight check can run before the package is installed. It runs the installer's own prerequisite checks and reports what passed, what failed, and whether the server will run with reduced monitoring. Run it on a representative server of each type before installation.
Staged rollout
We recommend a staged rollout: one server, then a small canary group, then the rest of the fleet. Stay on the stable update channel, or switch automatic updates off and update through an existing change process, and pin a version tag for container deployments.
Change-ticket summary
The summary below is written for a change ticket and can be filed as it stands.
| Hosts touched | The enrolled servers, plus one relay server if isolated segments are monitored. |
|---|---|
| Packages added | The LinuxGuard agent, from a signed LinuxGuard package repository that installation adds. |
| Accounts added | One dedicated service account. Installed from packages, the agent runs as this account, not as root. For container deployments, the documentation lists what the container needs. |
| Host changes | A monitoring sensor. On servers that support full monitoring, an optional security setting in the boot configuration. Nothing in the installation blocks existing security patching. |
| Reboot | Not needed to install. On servers that support full monitoring, the boot setting takes effect at the next reboot, which can be scheduled in a normal maintenance window. |
| Network | Outbound HTTPS on port 443 to LinuxGuard's service addresses, listed in the documentation. No inbound ports from the internet; a relay, if used, accepts connections only from inside the customer network. |
| Updates | Checked daily on the stable channel by default. Automatic updates can be switched off, so every update goes through change control. |
| Pre-checks | Run the preflight check on a representative server of each type before installation. |
| Back-out | Unenrol the server, then remove the package with the package manager; on Debian and Ubuntu, use purge rather than remove, so configuration, state and the service account go too. Two small host settings it adds stay until they are removed, and our documentation shows how. |
In the documentation: Quick start · CLI reference
How to remove it
Two-step removal
LinuxGuard can be removed at any time, in two steps: unenrol the server, then remove the package with the package manager. On Debian and Ubuntu, use purge rather than remove.
What stays behind
Two small host settings it adds stay until they are removed, and our documentation shows how. Left in place they are harmless, and they keep the server ready for a reinstall.
In the documentation: Updates and uninstallation
How to report a vulnerability
Report a security issue
Found a security issue in our website, platform, agent or API? Our vulnerability disclosure policy sets out what is in scope, what we commit to, and our safe harbour for good-faith research.
Contact: Email security@linuxguard.io
Security review questions?
Tell us what the review needs on the contact page, or start with a fixed-scope pilot on a defined set of servers.