Baselines
Baselines pillar in the LinuxGuard console — known-good snapshots of accounts, groups, SSH, and SUDO configuration with drift detection.
Baselines capture the known-good configuration state of accounts, groups, SSH, and SUDO across the fleet. Administrators define what "expected" looks like for each component type, and LinuxGuard compares every server against those expectations on each scan cycle. Deviations surface as Config Drift events in Zero Trust Enforcement, giving operators a direct line from "what we said the fleet should look like" to "where reality diverges."
Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.
Baselines differ from real-time monitoring. Real-time signals fire when an event occurs (a SUDO invocation, a syscall, a file write). Baselines describe a desired steady state — they answer "is this server still in the configuration we approved?" rather than "what just happened?" A server can be free of recent signals and still fail a baseline check, which is why both surfaces matter for posture.
Accounts
The Accounts baseline records which user accounts are expected to exist on a server, with optional checks on UID, primary GID, home directory, and login shell. A server that gains an unexpected account, loses an expected one, or has an account whose UID has changed surfaces a deviation. UID tracking is opt-in per baseline because not all environments require numeric ID consistency — environments using automated provisioning where UIDs may legitimately differ across servers typically disable it.
The accounts baseline is most useful for catching out-of-band account creation (an operator who adds a local account without using configuration management) and for spotting accounts that should have been removed but were not (an employee departure where one server kept the local account).
Groups
The Groups baseline records group memberships expected on each server, with optional GID tracking. The same opt-in pattern as accounts applies. Group membership baselines are particularly load-bearing for sensitive groups — wheel, sudo, docker, adm — where unexpected additions confer broad privilege.
A group baseline deviation often precedes a privilege-escalation event in Zero Trust Enforcement. An account quietly added to wheel on one server is visible here before the first sudo invocation makes it visible in Config Drift.
SSH config
The SSH config baseline captures the contents of system-level SSH client configuration — /etc/ssh/ssh_config and /etc/ssh/ssh_config.d/* — covering settings that govern outbound SSH connections from the server. Examples: default ciphers, MACs, HostKeyAlgorithms, IdentityFile preferences, ForwardAgent behavior, and StrictHostKeyChecking defaults.
A change to the client SSH config can silently weaken outbound encryption choices, enable agent forwarding where it was previously disabled, or relax host-key verification. Baseline tracking surfaces those changes whether they originated from package upgrades, hand edits, or configuration management runs that drifted from the documented standard.
SSHD config
The SSHD config baseline captures the contents of /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/* — the daemon-side configuration controlling inbound SSH on the server. This includes PermitRootLogin, PasswordAuthentication, PubkeyAuthentication, AllowUsers / AllowGroups, MaxAuthTries, ClientAliveInterval, and the AuthorizedKeysFile path.
SSHD config drift is high-impact because it changes who can log in and how. A baseline that flags PermitRootLogin yes returning after a hardening campaign, or PasswordAuthentication yes reappearing after key-only enforcement was rolled out, is exactly the kind of regression that this baseline exists to catch.
SUDO aliases
The SUDO aliases baseline tracks the Host_Alias, User_Alias, Runas_Alias, and Cmnd_Alias definitions in /etc/sudoers and /etc/sudoers.d/*. Aliases by themselves do not grant privilege — they are reusable names that downstream rules reference — but a change to an alias definition can broaden the reach of every rule that mentions it.
A Cmnd_Alias DEPLOY = /usr/bin/systemctl restart deploy-svc that quietly gains , /bin/bash is a privilege expansion of every rule referencing DEPLOY, even if no rule was edited directly.
SUDO defaults
The SUDO defaults baseline tracks Defaults lines in the sudoers configuration. These set tenant-wide behaviors: timestamp_timeout, passwd_tries, env_reset, secure_path, requiretty, lecture, and logfile. Defaults changes can weaken audit posture (a logfile removal that takes per-invocation logging offline) or relax authentication friction (timestamp_timeout extended from minutes to hours).
SUDO rules
The SUDO rules baseline tracks the user / group / runas / command rule lines in sudoers. This is the core surface of who-can-do-what under privilege escalation. Rule changes are the most common source of Config Drift events for the SUDO category, and a baseline gives operators the ability to define the approved rule set and surface every deviation from it.
Rules added through configuration management are visible here just as rules added by hand are — the baseline does not distinguish source, only whether the rule was expected. Rule attribution (who made the change and via which process) is provided by Config Drift in Zero Trust Enforcement.
Baseline settings
Baseline settings control how strictly each baseline category is enforced and which optional comparisons are included. The settings page exposes per-category toggles:
Track UID
Include numeric UID in account comparisons
Track GID
Include numeric GID in group comparisons
Include sudoers.d
Extend SUDO comparisons to drop-in directory files
Include sshd_config.d
Extend SSHD comparisons to drop-in directory files
Sensitive groups
Comma-separated group names that receive stricter scrutiny in drift attribution
Baseline refresh cadence
How often the agent re-scans each component for baseline comparison
Sensitive groups are a load-bearing concept — groups named here produce higher-severity drift events when membership changes, and surface in identity risk scoring with greater weight.
Data sources
Baselines are populated from agent telemetry — the agent scans accounts, groups, SSH config files, SSHD config files, and sudoers content on each run and reports them to the backend. Baseline state is per-server and per-component; comparison happens server-side at scan time. No external sources feed baselines.
The agent component performing each scan:
Accounts
/etc/passwd, /etc/shadow (presence only, content not collected)
Groups
/etc/group
SSH config
/etc/ssh/ssh_config, /etc/ssh/ssh_config.d/*
SSHD config
/etc/ssh/sshd_config, /etc/ssh/sshd_config.d/*
SUDO aliases / defaults / rules
/etc/sudoers, /etc/sudoers.d/*
Module gating
Baselines is part of the Identity Intelligence module. Tenants without the Identity Intelligence module see the Baselines section in the sidebar with an upgrade prompt; baseline scan data is collected by the agent regardless but is not surfaced for comparison without the module.
Subscription gating for individual baseline categories (per-component opt-in vs all-or-nothing) is documented in the console settings — categories may be selectively enabled on tenants where collection of certain config files is restricted by policy.
Cross-references
Related Concepts: Identity Intelligence (account / group / SSH key inventory), Zero Trust Enforcement (Config Drift consumes baseline deviations), Infrastructure (server-level Baselines tab)
Related How-to: Configure (baseline tunables in agent config)
Related: Console | Infrastructure | Zero Trust Enforcement | Identity Intelligence | Glossary
Last updated
Was this helpful?