Skip to main content

Host security

The agent watches a few security-relevant signals on the host, all read-only.

SSH activity​

On systemd hosts the journal probe reads new auth entries by cursor (no shell, and the log identifiers are validated against injection) and counts them into rate metrics. On non-systemd hosts the same numbers come from logtail over the auth log.

  • svc.ssh.auth_fail_rate: failed logins per second. A brute-force attack shows up as a spike here.
  • svc.ssh.accepted_rate: successful logins.
  • svc.ssh.root_login_rate: successful logins as root, worth alerting on for fleets where direct root access is not routine.

Failed logins also capture the source address. When failures cross a threshold, the agent folds the top attacking sources into one event, so the signal names who is hammering the host, not just how fast.

SSH configuration doors​

The sshd configuration is checked for the two doors attackers love: root reachable by password, and PasswordAuthentication yes. Both are reported as 0/1 metrics (svc.ssh.root_login_permitted, svc.ssh.password_auth_on). Root counts only when a password can reach it: PermitRootLogin yes with passwords and keyboard-interactive authentication switched off lets root in by key only, the same state as prohibit-password, and is not a finding. The check reads the effective configuration (sshd -T, the daemon's own resolved view including includes and defaults), not a regex over the file, so a global no with a scoped Match block exception reads correctly instead of raising a false alarm.

OOM kills​

The kernel shooting a process is never fine. svc.systemd.oom_kills_rate counts out-of-memory kills from the kernel journal, so the "my service just vanished" class of mystery has a metric.

File integrity monitoring​

The file probe can hash a file's content and the agent diffs that hash across runs. When it changes, the agent raises a kind=integrity event. The default set covers /etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, and service configs such as sshd_config. A useradd or an edited sudoers file surfaces as an integrity event.

Open ports​

Listening ports are already discovery facts (kind=port) with the owning process, so the open-port surface of a host is visible in inventory without a separate scan.

Anomaly detection​

The on-agent anomaly scorer (see Alert rules) also applies here: an unusual sustained change in these rates can raise an anomaly event on its own, locally, with no server cost.

Hardening scan​

An hourly, read-only scan checks the host against a focused subset of the CIS level-1 controls, the doors attackers actually use:

  • Permissions on /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, and sshd_config. Distribution norms are understood: the Debian group-readable shadow does not false-fail; only real write or world access does.
  • sshd doors: root login permitted, password authentication, empty passwords, X11 forwarding.
  • Kernel hardening: TCP SYN cookies, SUID core dumps, ASLR, ICMP redirects.
  • Presence checks: the audit daemon installed, a host firewall active.
  • Password policy: maximum password age and the default umask from login.defs.

Each run emits a score (svc.cis.score, the percentage of checks passed) with pass and fail counts, plus an event carrying the failed checks with severities, so the console can show what exactly is open and how bad. The scan reads files and /proc/sys only, executes nothing, and runs on Linux (it reports itself honestly as not applicable elsewhere). It is a hardening posture signal, not a full benchmark audit.