> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/concepts/concepts/console/baselines.md). # Baselines 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: | Setting | Purpose | | ------------------------ | ------------------------------------------------------------------------------- | | 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: | Baseline category | Agent surface | | ------------------------------- | ------------------------------------------------------------------- | | 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 CLI commands: [`config`](/reference/reference/cli/config.md) (baseline-related keys), [`probe`](/reference/reference/cli/probe.md) (per-component collection verification) * Related Concepts: [Identity Intelligence](/concepts/concepts/console/identity-intelligence.md) (account / group / SSH key inventory), [Zero Trust Enforcement](/concepts/concepts/console/zero-trust-enforcement.md) (Config Drift consumes baseline deviations), [Infrastructure](/concepts/concepts/console/infrastructure.md) (server-level Baselines tab) * Related How-to: [Configure](/configure/configure.md) (baseline tunables in agent config) *** **Related**: [Console](/concepts/concepts/console.md) | [Infrastructure](/concepts/concepts/console/infrastructure.md) | [Zero Trust Enforcement](/concepts/concepts/console/zero-trust-enforcement.md) | [Identity Intelligence](/concepts/concepts/console/identity-intelligence.md) | [Glossary](/reference/reference/glossary.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.linuxguard.io/concepts/concepts/console/baselines.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.