Write setup-complete marker on non-manager nodes

so-boot-highstate.service was never enabled outside managers: only the
manager branch of so-setup called mark_setup_complete, so the marker its
service.enabled gates on never existed on sensors, search nodes, receivers,
etc.

Move the marker state into salt.minion.boot_highstate as the sole owner
within a highstate. Non-managers never apply salt.minion during setup, so
reaching it means setup is done and the marker is unconditional -- this also
heals already-installed nodes. Managers keep the legacy startup_states gate,
since they do highstate mid-setup.

Also add the marker to setup.virt for salt-cloud guests (replacing the
startup_states line removed in fabecb82) and to so-setup's non-manager branch.

salt/common/tools/sbin/so-log-check

@@ -154,6 +154,8 @@ if [[ $EXCLUDE_FALSE_POSITIVE_ERRORS == 'Y' ]]; then
     EXCLUDED_ERRORS="$EXCLUDED_ERRORS|id.orig_h"                    # false positive (zeek test data)
     EXCLUDED_ERRORS="$EXCLUDED_ERRORS|emerging-all.rules"           # false positive (error in rulename)
     EXCLUDED_ERRORS="$EXCLUDED_ERRORS|invalid query input"          # false positive (Invalid user input in hunt query)
+    EXCLUDED_ERRORS="$EXCLUDED_ERRORS|no data available for the requested dates" # false positive (pcap cypress test submits a job with an empty time frame)
+    EXCLUDED_ERRORS="$EXCLUDED_ERRORS|no job processor"             # false positive (same empty-time-frame job on import nodes, where no pcap processor runs)
     EXCLUDED_ERRORS="$EXCLUDED_ERRORS|example"                      # false positive (example test data)
     EXCLUDED_ERRORS="$EXCLUDED_ERRORS|status 200"                   # false positive (request successful, contained error string in content)
     EXCLUDED_ERRORS="$EXCLUDED_ERRORS|app_layer.error"              # false positive (suricata 7) in stats.log e.g. app_layer.error.imap.parser | Total | 0

salt/salt/minion/boot_highstate.sls

@@ -3,6 +3,8 @@
 # https://securityonion.net/license; you may not use this file except in compliance with the
 # Elastic License 2.0.
 
+{% from 'vars/globals.map.jinja' import GLOBALS %}
+
 # Manages /etc/systemd/system/so-boot-highstate.service, a Type=oneshot
 # RemainAfterExit=yes unit that runs `salt-call state.highstate` exactly once
 # per system boot. Replaces the legacy `startup_states: highstate` minion
@@ -19,9 +21,45 @@ so_boot_highstate_unit_file:
     - onchanges_in:
       - module: systemd_reload
 
-# Only enable once setup is complete. Until then the gate file is missing and
-# the unit's own ConditionPathExists would no-op it anyway -- this just keeps
-# `systemctl is-enabled` honest for the sync_es_users gate.
+# Sole owner of the /opt/so/state/setup-complete marker within a highstate run.
+# (mark_setup_complete in setup/so-functions writes it directly during setup,
+# and setup.virt writes it for hypervisor guests, but neither of those is ever
+# part of a highstate.)
+#
+# Non-manager: salt.minion is never applied during setup. The non-manager branch
+# of setup/so-setup only reaches salt through --local applies of
+# salt.mine_functions, salt.python_modules, salt.patch.x509_v2 and libvirt.*;
+# the first highstate is pushed later by the manager via orch.deploy_newnode.
+# So if this state is rendering on a non-manager, setup is finished by
+# definition and the marker is unconditionally correct. This is what heals
+# nodes installed after the startup_states removal but before this fix, which
+# have neither the marker nor the legacy line the upgrade gate below keys off.
+#
+# Manager: managers DO apply salt.minion mid-setup (so-setup applies salt.master,
+# then the manager state whose init.sls includes salt.minion, then a full
+# highstate -- all before setup completes). Marking a manager complete there
+# would install the every-minute so-user_sync cron from manager/sync_es_users.sls
+# against a half-configured manager, racing so-user add for the so-user.lock.
+# Managers therefore only get the marker from the legacy upgrade signal; fresh
+# manager installs get it from mark_setup_complete in setup/so-functions at the
+# right moment.
+#
+# replace: false means an existing marker is never rewritten.
+mark_setup_complete:
+  file.managed:
+    - name: /opt/so/state/setup-complete
+    - replace: false
+    - makedirs: True
+{% if GLOBALS.is_manager %}
+    - onlyif: "grep -qx 'startup_states: highstate' /etc/salt/minion"
+{% endif %}
+    - require_in:
+      - service: so_boot_highstate_service
+
+# Only enable once setup is complete. The unit's own ConditionPathExists already
+# no-ops it before then, so this is belt-and-braces; it also preserves the
+# operator-facing invariant that an enabled so-boot-highstate.service means the
+# node finished setup.
 so_boot_highstate_service:
   service.enabled:
     - name: so-boot-highstate.service

salt/salt/minion/init.sls

@@ -87,27 +87,17 @@ set_log_levels:
 # so-boot-highstate.service (managed in salt.minion.boot_highstate), which
 # runs once per system boot only. Strip the line from /etc/salt/minion on
 # upgrade; both the commented and uncommented forms historically existed.
+#
+# Ordered after mark_setup_complete (salt.minion.boot_highstate) because on a
+# manager that state's gate greps for this very line -- deleting it first would
+# lose the upgrade bridge that lets an upgraded manager enable the boot unit.
 remove_startup_states:
   file.line:
     - name: /etc/salt/minion
     - match: 'startup_states: highstate'
     - mode: delete
-
-# Upgrade-path bridge: systems that already passed setup under the old gate
-# (`grep -x 'startup_states: highstate' /etc/salt/minion`) get a /opt/so/state/setup-complete
-# marker so so-boot-highstate.service can be enabled and the so-user_sync cron
-# in sync_es_users.sls keeps installing. Setup-in-progress systems instead get
-# the marker from `mark_setup_complete` in setup/so-functions at the right
-# moment. `replace: false` means we never overwrite a marker once written.
-mark_setup_complete_for_upgrades:
-  file.managed:
-    - name: /opt/so/state/setup-complete
-    - replace: false
-    - makedirs: True
-    - onlyif: "grep -qx 'startup_states: highstate' /etc/salt/minion"
-    - require_in:
-      - file: remove_startup_states
-      - service: so_boot_highstate_service
+    - require:
+      - file: mark_setup_complete
 
 {% endif %}
 

salt/setup/virt/setSalt.sls

@@ -8,6 +8,18 @@ set_role_grain:
     - name: role
     - value: so-{{ grains.id.split("_") | last }}
 
+# Hypervisor guests provisioned by salt-cloud never run setup/so-setup, so
+# nothing else marks them setup-complete at provisioning time. Replaces the
+# 'startup_states: highstate' line this state used to append; the marker gates
+# so-boot-highstate.service (see salt/salt/minion/boot_highstate.sls).
+# Deliberately no GLOBALS import -- this state tree runs before the guest's
+# pillars exist (see the comment at the top of salt/common/packages.sls).
+mark_setup_complete_vm_guest:
+  file.managed:
+    - name: /opt/so/state/setup-complete
+    - replace: false
+    - makedirs: True
+
 enable_salt_minion:
   service.enabled:
     - name: salt-minion

salt/zeek/defaults.yaml

@@ -15,7 +15,7 @@ zeek:
       MailHostUpDown: 0
       LogRotationInterval: 3600
       LogExpireInterval: 0
-      StatsLogEnable: 1
+      StatsLogEnable: 0
       StatsLogExpireInterval: 0
       StatusCmdShowAll: 0
       CrashExpireInterval: 0

salt/zeek/disabled.sls

@@ -23,6 +23,11 @@ zeekpacketlosscron:
     - identifier: zeekpacketlosscron
     - user: root
 
+zeekctlcron:
+  cron.absent:
+    - identifier: zeekctlcron
+    - user: root
+
 {% else %}
 
 {{sls}}_state_not_allowed:

salt/zeek/enabled.sls

@@ -87,6 +87,21 @@ zeekpacketlosscron:
     - month: '*'
     - dayweek: '*'
 
+# LogExpireInterval, StatsLogExpireInterval and CrashExpireInterval are only acted on by
+# 'zeekctl cron', so run it on the interval upstream recommends. This also restarts any
+# node that died unexpectedly. Runs as root because the script needs the docker socket;
+# it drops to the zeek user inside the container.
+zeekctlcron:
+  cron.present:
+    - name: /usr/sbin/so-zeek-cron > /dev/null 2>&1
+    - identifier: zeekctlcron
+    - user: root
+    - minute: '*/5'
+    - hour: '*'
+    - daymonth: '*'
+    - month: '*'
+    - dayweek: '*'
+
 {% else %}
 
 {{sls}}_state_not_allowed:

salt/zeek/soc_zeek.yaml

@@ -58,6 +58,86 @@ zeek:
       CompressLogs:
         description: This setting enables compression of Zeek logs. If you are seeing packet loss at the top of the hour in Zeek or PCAP you might need to disable this by seting it to 0. This will use more disk space but save IO and CPU.
         helpLink: zeek
+      LogExpireInterval:
+        description: >-
+          How long to keep rotated Zeek logs in /nsm/zeek/logs. A bare number means DAYS, so 7 means 7 days.
+          You may also give an explicit unit, such as "7 days" or "12 hr". Use 0 to keep logs forever.
+          This value must not be shorter than LogRotationInterval (3600 seconds by default), so the smallest
+          usable value is 1 hr - Zeek will fail to start if it is shorter. Expiry is applied by "zeekctl cron",
+          which runs every 5 minutes, and removes log files older than this based on their modification time.
+        regex: ^(0|[1-9][0-9]*( ?(day|hr)s?)?)$
+        regexFailureMessage: Enter 0, or a positive number optionally followed by "day" or "hr" (for example 7, "7 days", or "12 hr"). Minutes are not accepted because a log expire interval shorter than the log rotation interval prevents Zeek from starting.
+        helpLink: zeek
+        advanced: True
+      StatsLogEnable:
+        description: >-
+          Set to 1 to have "zeekctl cron" write node statistics to /nsm/zeek/logs/stats. This is
+          disabled because the CPU and memory portion depends on the "top" command, which the Zeek
+          container does not include, so every run records an error for each node instead. The
+          interface packet counters it also collects are not used anywhere in Security Onion, which
+          tracks Zeek packet loss separately through packetloss.log and Telegraf. It is read only
+          for that reason.
+        regex: ^[01]$
+        regexFailureMessage: You must enter 0 or 1.
+        helpLink: zeek
+        advanced: True
+        readonly: True
+      StatsLogExpireInterval:
+        description: >-
+          Number of days to keep entries in the Zeek stats log, or 0 to keep them forever.
+          Applied by "zeekctl cron", which runs every 5 minutes. This has no effect unless
+          StatsLogEnable is turned on, which it is not by default.
+        regex: ^[0-9]+$
+        regexFailureMessage: You must enter a whole number of days, or 0 to keep entries forever.
+        helpLink: zeek
+        advanced: True
+      CrashExpireInterval:
+        description: >-
+          Number of days to keep Zeek crash directories, or 0 to keep them forever.
+          Applied by "zeekctl cron", which runs every 5 minutes.
+        regex: ^[0-9]+$
+        regexFailureMessage: You must enter a whole number of days, or 0 to keep crash directories forever.
+        helpLink: zeek
+        advanced: True
+      MinDiskSpace:
+        description: >-
+          Percentage of free disk space below which ZeekControl reports a warning, or 0 to disable the check
+          entirely. The Zeek container does not include a mail program, so the warning is not emailed - it
+          appears in the output of "zeekctl cron" instead. This setting never deletes anything - cleanup based
+          on disk usage is handled separately by so-sensor-clean.
+        regex: ^([0-9]|[1-9][0-9]|100)$
+        regexFailureMessage: You must enter a percentage between 0 and 100.
+        helpLink: zeek
+        advanced: True
+      MailTo:
+        description: >-
+          Address that ZeekControl would send mail to, covering cron output and crash reports, and the address
+          Zeek's notice framework would use. The Zeek container does not include a mail program, and Security
+          Onion never enables the notice email action, so no mail is sent and this address is unused. It is
+          read only for that reason.
+        helpLink: zeek
+        advanced: True
+        readonly: True
+      MailConnectionSummary:
+        description: >-
+          Set to 1 to email the hourly connection summary. This only controls the emailed copy - the summary is
+          generated and archived with the other Zeek logs either way. The Zeek container does not include a mail
+          program, so no mail is sent and this setting has no effect. It is read only for that reason.
+        regex: ^[01]$
+        regexFailureMessage: You must enter 0 or 1.
+        helpLink: zeek
+        advanced: True
+        readonly: True
+      MailHostUpDown:
+        description: >-
+          Set to 1 to report when a Zeek node changes between the up and down states. The Zeek container does
+          not include a mail program, so this notification cannot be emailed. It is read only for that reason.
+          Host status detection still runs regardless of this setting - only the notification is affected.
+        regex: ^[01]$
+        regexFailureMessage: You must enter 0 or 1.
+        helpLink: zeek
+        advanced: True
+        readonly: True
   policy:
     custom:
       filters: 

salt/zeek/tools/sbin/so-zeek-cron

@@ -0,0 +1,24 @@
+#!/bin/bash
+
+# Copyright Security Onion Solutions LLC and/or licensed to Security Onion Solutions LLC under one
+# or more contributor license agreements. Licensed under the Elastic License 2.0 as shown at
+# https://securityonion.net/license; you may not use this file except in compliance with the
+# Elastic License 2.0.
+
+# Run zeekctl's periodic maintenance tasks. This is what actually enforces
+# LogExpireInterval, StatsLogExpireInterval and CrashExpireInterval - without a periodic
+# 'zeekctl cron' those settings are inert no matter what they are set to.
+
+# This also restarts any node that died unexpectedly, and marks it crashed so a crash report
+# is produced. That is upstream's default cron behavior and it recovers a single node in
+# place. The beacon in salt/_beacons/zeek.py is the only other recovery path, it is disabled
+# by default (healthcheck:enabled), and it removes and recreates the whole container, so
+# letting zeekctl handle a single dead worker avoids the heavier restart.
+
+if ! docker ps --filter name=so-zeek --format '{{.Names}}' | grep -q '^so-zeek$'; then
+  exit 0
+fi
+
+# Run as the zeek user so the stats logs and zeekctl-config.sh this writes stay owned by
+# uid 937 rather than root.
+docker exec so-zeek runuser -l zeek -c '/opt/zeek/bin/zeekctl cron'

setup/so-setup

@@ -833,6 +833,7 @@ if ! [[ -f $install_opt_file ]]; then
 		check_sos_appliance
 		drop_install_options
 		hypervisor_local_states
+		mark_setup_complete
 		verify_setup
 	fi