Linux Hardening Standards

Linux hardening standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies to hardening the Linux operating system and proving it with a measurement: choosing and applying a baseline (CIS, STIG, ANSSI-BP-028, CCN-STIC/ENS), automating it as code, auditing it with a scanner, the agreed score and the handling of drift. It covers minimal surface, kernel parameters, accounts/sudo/PAM, SSH, auditd, integrity and measured boot, service containment with systemd, mount options and SUID, security updates and livepatching, and a hardened golden image.

Triggers: oscap, ssg/scap-security-guide, lynis, cis, stig, anssi_bp28, ccn-stic, sshd_config, /etc/sysctl.d/*.conf, /etc/audit/rules.d/*.rules, auditd.conf, faillock.conf, pwquality.conf, login.defs, /etc/sudoers.d/, /etc/modprobe.d/*.conf, fstab, aide.conf, systemd-analyze security, unattended-upgrades, dnf-automatic, kpatch, "baseline", "benchmark", "compliance score", "the hardening broke the service".

Governing principle: a baseline without a measurement is an opinion, and a baseline applied blind is a scheduled service outage. Real hardening is three simultaneous things — applying it as code, measuring it with a scanner and documenting every exception with an owner and a reason. Missing any of the three turns the work into compliance theatre.

Not applicable: see selinux-standards (mandatory access control in depth: policy, contexts, booleans, AVC diagnosis, AppArmor — here MAC in enforcing is only required as a baseline control and measured, not explained in terms of how it is operated nor how policy is written), onprem-standards (platform umbrella: hardware, the OOB/BMC management plane, hypervisor, fleet topology, fleet patching cadence, platform invariants — its §1.3 invariants are inviolable and this skill develops them at the OS layer), bash-linux-scripting-standards (the scripts that run anything from here: set -Eeuo pipefail, ShellCheck, bats), iac-standards (Ansible/Terraform as a tool: role structure, Molecule, lint and CI of the IaC repo — here only which hardening role is chosen and with what criteria it is applied), vulnerability-management-standards (CVE triage with CVSS/EPSS/KEV, remediation SLA, VEX, EOL tracking — they prioritise the patch, you harden so the patch matters less), grc-compliance-standards (ENS/ISO 27001/NIST CSF as a framework, SoA, risk acceptance and audit evidence — here the technical control and its proof, which is what they consume as evidence), networking-standards (network design: VLANs, routing, firewall policy between zones, DNS, VPN; the host firewall belongs to this skill — nftables/firewalld on the server itself as a baseline control: default-deny inbound, filtered egress, a versioned ruleset —, whereas which flow is allowed between zones and why is decided by the network topology), cryptography-pki-standards (the choice of algorithms and their cryptographic justification, LUKS key management, SSH certificate issuance and the internal PKI — here only the configuration that consumes them), identity-access-management-standards (IdP, SSO, MFA, JIT/PAM elevation and the bastion as a service — here the local configuration: sudoers, pam_faillock, AllowGroups), kubernetes-standards (declarative Pod hardening, securityContext, admission), observability-standards (where and how auditd logs are collected, retained and correlated), appsec-standards (application code vulnerabilities), homelab-standards (a personal lab: the boundary is the rigour demanded, not the size), offensive-security-standards (offensive verification of the hardening, with scope and authorisation), ctf-lab-standards (a disposable training lab), developer-workstation-standards (a boundary that really does collide: here the hardening of the server and the fleet — CIS/STIG baseline, sysctl, auditd, sudoers, SELinux/AppArmor, applied by centralised configuration —; there the workstation, whose threat model is different: disk encryption, keys in hardware, editor extensions and curl | sh as a supply chain, and development credentials. A server baseline applied to a development workstation does not harden it, it makes it unusable), endpoint-security-standards (third-party EDR/XDR and the posture of the encryption guard across the fleet are theirs — including the agent's real limits on Linux —; here the baseline control applied by centralised configuration and measured with oscap).

In addition: container-runtime-security-standards (seccomp, eBPF/Falco, container escape detection and runtime security), detection-engineering-standards (what is done with auditd telemetry — Sigma rules, use cases, SIEM), bcdr-standards (RTO/RPO and continuity), linux-administration-standards (day-to-day OS work, systemd, packages, users without a security angle), rhel-fedora-standards (the specifics of the RHEL family — dnf5, rpm-ostree, bootc, image builder).

2. Default decisions

Verify the latest version on the web before pinning it in a real project (§8). The facts are from August 2026 and baseline content (CIS, SSG) is revised every few weeks.

3. Structure and conventions

3.1 The baseline is applied with documented exceptions, never blind

There are CIS controls that break real services — noexec on /var or /tmp against installers and runtimes that execute from there, nodev on paths a container needs, umask 027 against services that share a group, restricting unprivileged user namespaces against rootless Podman or browsers, cron/at restrictions, SSH algorithms that leave out old clients, pam_pwquality against service accounts. The baseline is not applied 100%: it is applied 100% minus a set of explicit exceptions.

Mandatory exception format, in the repo, next to the code that implements it:

The exception is implemented as a profile tailoring (autotailor, XCCDF/JSON tailoring files) so the scanner does not count it as a failure. An exception that keeps appearing as a finding in every report trains the team to ignore the reports.

3.2 Order of work (non-negotiable)

1. Measure before touching: oscap xccdf eval with the target profile against the host as it is. That report is the baseline and the argument for the conversation.
2. Apply in non-production the full role, with no exceptions, and break things there.
3. Catalogue what broke → exceptions (§3.1) + tailoring.
4. Apply in production in waves, with a functional smoke test after each wave (§4).
5. Re-measure and set the agreed score as the CI threshold.
6. Watch the drift continuously; every deviation is a finding with an owner.

Never: applying the full role directly to production "because it is a standard baseline".

3.3 Minimal surface

• Packages: a minimal installation as the starting point (Minimal Install, debootstrap, --no-install-recommends). Everything installed afterwards is justified. No compilers, no unnecessary network clients (telnet, ftp, rsh, tftp), no X servers on servers.
• Services and ports: systemctl list-units --type=service --state=running and ss -lntup against the role's expected list. An undeclared listening port is a finding.
• Unnecessary kernel modules, with a real blacklist (install <mod> /bin/true in /etc/modprobe.d/, not just blacklist, which does not prevent on-demand loading): exotic filesystems (cramfs, freevxfs, jffs2, hfs, hfsplus, udf, squashfs if unused), unusual network protocols (dccp, sctp, rds, tipc), usb-storage on servers, firewire-core, bluetooth. Verify that the blacklisting survives the initramfs.
• Accounts: no system accounts with a valid shell; no orphan accounts; explicit nologin. No shared local accounts — all access is named.

3.4 Kernel and parameters

No "list of sysctls copied from a blog". Every parameter set is justified and grouped in /etc/sysctl.d/ by purpose, with the file versioned (careful: on Debian 13 /etc/sysctl.conf is no longer honoured — you have to write into sysctl.d, something devsec.hardening fixed in its 10.4 line).

The axes, with the criterion for why:

• Network: anti-spoofing (rp_filter), ignore ICMP redirects and source routing, do not forward packets unless the host is a router, tcp_syncookies, and accept_ra/disable_ipv6 only if IPv6 really is not used — disabling IPv6 "just in case" breaks modern services and hardens nothing. The filtering policy itself belongs to the firewall, not to sysctl.
• Kernel information exposure: kernel.kptr_restrict=2, kernel.dmesg_restrict=1, a high kernel.perf_event_paranoid on hosts without profiling, fs.protected_hardlinks/_symlinks/ _fifos/_regular. Real operational cost: they make diagnosis harder — decide it, do not inherit it.
• Tracing and dump restrictions: kernel.yama.ptrace_scope ≥ 1 (2 or 3 on hosts that do not debug anything; devsec.hardening 10.6.0 hardened it explicitly in May 2026), fs.suid_dumpable=0, core dumps disabled or directed to a controlled path (a core dump can contain keys in memory).
• Boot and code chain: mandatory module signing, kernel.modules_disabled=1 at the end of boot on fixed-function hosts, kexec_load_disabled=1, and lockdown — integrity as the floor (it blocks modifying the running kernel and loading unsigned modules), confidentiality on hosts handling secrets, measuring first what breaks (profiling, debugging, hibernation, some proprietary drivers). lockdown transitions are one-way: you can only harden, never relax at runtime. On EFI x86/arm64 many distros enable it by themselves with Secure Boot. A limitation declared by its author: it protects the integrity of the kernel, not of the whole system — complement it with dm-verity and MAC.
• Unprivileged namespaces: on Ubuntu 24.04+/26.04 the restriction goes through AppArmor (kernel.apparmor_restrict_unprivileged_userns=1 by default). Before disabling it for an app that "does not start", understand what uses it: it is historic escalation surface, and Qualys published in Mar 2025 three bypasses of that restriction (via aa-exec to permissive profiles and via busybox's default profile). On RHEL 10 the default configuration grants user namespaces to unprivileged users, which widened the impact of recent kernel flaws: review it.
• CPU mitigations: on by default, always. If the cost is unacceptable, it is measured with the real workload, the loss is documented, it is scoped to specific hosts and it is approved by the risk owner. mitigations=off on a multi-tenant host or one running third-party code is forbidden (§7). A verified reference for the real cost: VMSCAPE (CVE-2025-40300, Sep 2025; guest→hypervisor leak on all AMD Zen 1-5 generations and Coffee Lake) is mitigated with conditional IBPB after VMexit (vmscape=, vmscape=force with untrusted guests) at a cost of ~10% with an emulated device and ~1% on Zen 4 — that is the order of magnitude of the conversation, not "the mitigations cost half the performance". A recurring pattern: the kernel patch alone is not enough, microcode/UEFI is needed in parallel. Real status: lscpu and /sys/devices/system/cpu/vulnerabilities/*.

3.5 Accounts, sudo and PAM

• Named and scoped sudo: rules per group, with explicit commands and absolute paths, in versioned /etc/sudoers.d/ files validated with visudo -c. Defaults logfile or log_output for elevated commands. NOPASSWD: ALL is forbidden (§7); NOPASSWD scoped to a specific command for automation is acceptable if the command does not allow escaping to a shell (careful with vi, less, find -exec, tar --to-command, package managers).
• sudo is first-class attack surface, not inert infrastructure: CVE-2025-32462 and CVE-2025-32463 (root escalation via --chroot, CVSS 9.3, in the CISA KEV catalogue since 29 Sep 2025, and exploitable without being in sudoers) were fixed in sudo 1.9.17p1. Upstream has announced that the chroot option will be removed. Verify the installed version, and forbid the use of --chroot/-R in your rules.
• pam_faillock configured in /etc/security/faillock.conf (lockout after N failures, a window, a non-zero unlock_time unless explicitly required, and excluding root from permanent lockout so you do not lock yourself out). Verify the unlock with faillock --user X --reset before considering it done. In the RHEL family, the PAM stack is managed with authselect: editing the files by hand means the SSG rules do not apply and the next authselect apply-changes reverts your change.
• pam_namespace disabled unless genuinely used: CVE-2025-6020 and its complete fix CVE-2025-8941 (CVSS 7.8, with a public exploit) allow root escalation via symlinks over paths controlled by the user. Fixed in linux-pam 1.7.1. If you need it, mount with nosymfollow and do not point it at user-writable paths.
• An evidence-based password policy, not a baroque one: modern evidence (NIST SP 800-63B) calls for a high minimum length + checking against lists of compromised passwords, and advises against mandatory periodic expiry and composition rules. The CIS baseline still asks for expiry and complexity: if your framework forces you, comply; if you have room, document the deviation towards the better practice with the same rigour as any other exception. Checking against lists: pam_pwquality with a dictionary or a source of leaked credentials. Local hashing: yescrypt or SHA-512 with a high round count depending on the distro.
• Limits: /etc/security/limits.d/ with bounded nproc/nofile/core to contain fork bombs and descriptor exhaustion; it complements, it does not replace, systemd's limits.
• umask 027 (or 077 on sensitive hosts) in /etc/login.defs and in the shell profile, with care for services that share a group. UMask= in the systemd unit for the service.
• Sessions: TMOUT/ClientAliveInterval for idle sessions, a legal banner (/etc/issue.net) — the banner is a compliance control, not a security one: treat it as such.

3.6 Hardened SSH

• Baseline: PermitRootLogin no, PasswordAuthentication no, KbdInteractiveAuthentication no, PermitEmptyPasswords no, AllowGroups <group> (an explicit allowlist, not a denylist), X11Forwarding no, a low MaxAuthTries, LogLevel VERBOSE (it records the fingerprint of the key used, which is what you will need in the investigation).
• Post-quantum — verified Aug 2026 (OpenSSH 10.4, 06 Jul 2026): 9.9 added mlkem768x25519-sha256; 10.0 (Apr 2025) made it the default KEX; 10.1 (Oct 2025) makes the ssh(1) client warn when the server does not offer a post-quantum KEX ("WARNING: connection is not using a post-quantum key exchange algorithm") and adds WarnWeakCrypto to ssh_config to silence it. The previous hybrid sntrup761x25519-sha512@openssh.com (default since 9.0) is still supported and serves to interoperate with 9.0-9.8 servers. Criterion: the server must negotiate mlkem768x25519-sha256; silencing the warning on the client instead of updating the server is forbidden (§7). OpenSSH does not yet have post-quantum signatures for identity keys: the warning is about KEX only.
• Algorithms: do not copy KexAlgorithms/Ciphers/MACs lists from three years ago — a list pinned by hand ages towards weaker than the current binary's default (since 10.0 the default cipher order is ChaCha20-Poly1305 → AES-GCM → AES-CTR: an old list undoes that improvement). Start from the installed version's default and remove, do not rebuild. Verify what it actually negotiates (ssh -Q kex, sshd -T). DSA was removed entirely in OpenSSH 10.0; RSA only with SHA-2 and ≥ 3072 bits if there is no alternative; by default ed25519 or ed25519-sk (FIDO2). Migration note: 10.x changed Match to shell-style quoting — it can break existing configs, and there is a security fix in DisableForwarding, which did not disable X11 or agent forwarding as documented.
• Short-lived SSH certificates > authorized_keys: an internal SSH CA with certificates lasting hours removes the problem of revocation and of orphan keys scattered across the fleet (TrustedUserCAKeys, principals, HostCertificate to authenticate the server too and kill TOFU). Issuance, the CA and its custody: cryptography-pki-standards; JIT elevation and the bastion as a service: identity-access-management-standards. Here: the host only trusts the CA and AllowGroups.
• Access only via a bastion, with Match Address restricting the source and no direct access from user networks. Any change to sshd_config is validated with sshd -t and reloaded with a second session open (§4).

3.7 auditd

• A minimal set of useful rules. A list of 400 rules copied from a generic repo produces gigabytes a day, saturates the disk, degrades the host and nobody reads it: it is signal loss disguised as compliance. Detection intelligence (TTPs, tool signatures) lives in the SIEM as Sigma rules, not in the auditd ruleset — see detection-engineering-standards.
• A defensible core: changes to /etc/passwd, /etc/shadow, /etc/group, sudoers and sudoers.d; execution of relevant SUID/SGID binaries; execve of shells by service accounts; module load/unload; time changes; mounts; modification of auditd's own configuration and of SSH's; denied accesses (EACCES/EPERM) on critical paths. Every rule with -k <key> so it can be searched and correlated.
• Syntax and deployment: syscall rules require -a always,exit (a bare -S execve generates nothing); human-user rules use -F auid>=<UID_MIN> -F auid!=unset substituting UID_MIN from /etc/login.defs at deployment time (auditd has no variables); -e 2 at the end to make the ruleset immutable only when the set is stable (it requires a reboot to change it). Verification: augenrules --check, augenrules --load, auditctl -l, auditctl -s.
• Operation: in the RHEL family, systemctl reload auditd does not work (service auditd restart or augenrules --load); since audit-4.0 the rules are loaded via audit-rules.service.
• Integrity and retention: /var/log/audit on its own partition (auditd filling the root disk is an outage, and space_left_action/admin_space_left_action with SUSPEND silently stop auditing — decide between availability and auditing, and document it). Forwarding to the SIEM with audisp-syslog/audisp-remote from /etc/audit/plugins.d/ (on Debian/Ubuntu it requires audispd-plugins). The local log is weak evidence: an attacker with root edits it; the remote copy, with a synchronised clock, is the one that counts. Where it goes and how long it is retained, in observability-standards.

3.8 Integrity and boot

• Secure Boot enabled and kernel + modules signed (with your own MOK if you compile out-of-tree modules). Without Secure Boot, lockdown is not a real boundary.
• TPM 2.0 with measurement: the PCRs measure the boot chain; useful only if something checks the measurement — sealing LUKS keys to PCRs or remote attestation. A TPM nobody queries is an expensive chip. Beware the fragility of PCRs and the attack on PCR 7 on its own (§2).
• LUKS2 on disks with data, and on the backups. Unattended: Clevis/Tang (two or more Tang servers so as not to create a SPOF; sss with a threshold — Tang stores no secrets) or TPM2 with a signed policy. Hard rule: if the host does not boot without a human, it is not in production.
• AIDE (or the agent's FIM) with the database signed and stored off the host, initialised after applying the baseline and re-initialised after every approved change — otherwise everyone learns to ignore its reports.

3.9 Service containment with systemd (a front-line hardening control)

systemd sandboxing is a real containment control and complementary to MAC: MAC defines what a domain can touch according to its label; systemd trims what the process can ask of the kernel (namespaces, capabilities, syscalls, FS views). Both are applied; systemd-analyze security explicitly ignores SELinux and AppArmor, so a good score does not replace enforcing nor the other way round.

Every unit of your own (and every third-party unit exposing the network) carries, as a floor: a dedicated User= or DynamicUser=yes, NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes, PrivateTmp=yes, PrivateDevices=yes, ProtectKernelTunables=yes, ProtectKernelModules=yes, ProtectKernelLogs=yes, ProtectControlGroups=yes, ProtectClock=yes, ProtectHostname=yes, ProtectProc=invisible, RestrictSUIDSGID=yes, RestrictRealtime=yes, RestrictNamespaces=yes, LockPersonality=yes, CapabilityBoundingSet= (empty, with only the indispensable added), SystemCallFilter=@system-service + SystemCallArchitectures=native, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX, explicit ReadWritePaths=, IPAddressDeny=any + IPAddressAllow= when the service talks to known destinations.

• Threshold: systemd-analyze security <unit> gives an exposure level from 0.0 to 10.0, with predicates (UNSAFE / EXPOSED / MEDIUM / OK). Target < 4.0 on your own services; measure and record the value before/after. Since systemd v250 you can pass a JSON policy with your own requirements and compare units against it: that is what goes into CI, not a remembered number. Official caveat: it does not analyse the program's internal hardening, and there are services (sshd, crond, atd) that score badly by design — do not "fix" them blindly.
• Overrides in /etc/systemd/system/<unit>.d/override.conf, never editing the package's unit (§7). Relevant release notes: v259 (17 Dec 2025) moves libselinux, pam, audit, libseccomp to dlopen and stops linking libcap — verify your minimal image includes them before assuming the sandbox is active; v260 (17 Mar 2026) removes support for SysV scripts (systemd-sysv-generator, rc-local.service); v261 is the current line.
• MemoryDenyWriteExecute=yes only where the runtime tolerates it (it breaks JIT: JVM, .NET, V8). It is a good example of a control that is tested, not presumed.

3.10 Filesystem, mounts and SUID

• Partitioning: /var, /var/log, /var/log/audit, /tmp and /home separated — the real goal is that no disk consumer can take the host down nor prevent logging.
• Mount options: nodev on everything that is not / or /dev; nosuid on /tmp, /var/tmp, /home, /dev/shm and network mounts; noexec on /tmp, /var/tmp and /dev/shm measuring first (installers, pip, package managers and some runtimes execute from /tmp; the exception, if any, is your own TMPDIR, not removing noexec).
• SUID/SGID binaries: an explicit inventory, compared at every audit (find / -xdev -type f \( -perm -4000 -o -perm -2000 \)). A new undeclared SUID is a security finding, not noise. Remove setuid from those not in use. Prefer scoped capabilities or systemd (AmbientCapabilities=) over a new SUID.
• /boot mounted with nodev,nosuid,noexec and a GRUB password for editing the boot line on hosts with uncontrolled physical access (useful precisely because selinux=0 or init=/bin/bash are written there).

3.11 Golden image

• The hardening is applied in the image, not host by host: oscap xccdf generate fix --fix-type kickstart or oscap-im for bootc/Image Mode images (OpenSCAP 1.4.x), or the profile's Ansible remediation, integrated into the build (image builder, Packer).
• The image is verified with the same scanner and the same profile as the fleet, in the pipeline, and it is published signed and versioned. Build once, promote the same artifact: the image that is audited is exactly the one that gets deployed.
• The image carries zero secrets: no pre-embedded SSH host keys (regenerate on first boot), no credentials, no builder's authorized_keys.

4. Quality gates (they break the build or the deployment)

In increasing cost order:

1. Lint and syntax validation before any application: visudo -c, sshd -t, augenrules --check, nft -c -f, ansible-lint. Cheap, and it avoids most access lockouts.
2. Application in check mode in non-production (--check --diff) and review of the diff. Warning: the ansible-lockdown roles do not support check mode — do not use it as your only net.
3. Compliance scan in CI over the golden image, with the project's profile and tailoring: oscap xccdf eval --profile <profile> --tailoring-file <t.xml> --results-arf arf.xml --report report.html. The build breaks if the score drops below the agreed threshold or if a new failure appears that is not covered by a current exception. The threshold goes up over time; it is never lowered to make the build pass (§7).
4. Post-hardening functional smoke test: the decisive gate. After hardening you check that the service really responds (port, health endpoint, synthetic transaction, real authentication), not that systemd says active. Hardening without this test is a gamble.
5. An access test with a rescue net: changes to SSH, PAM, the firewall or sudoers are applied with a second session open or an OOB console available, and a fresh login is validated before closing the first one. Non-negotiable.
6. Continuous fleet scanning (Wazuh SCA or equivalent) with drift as a finding: a ticket with an owner and a date, just like a vulnerability. A host that drifts from the baseline between audits is exactly the one that will get you compromised.
7. Baseline verification after every change touching the OS (a major upgrade, a new role, a new service): automatic rescan and comparison against the previous report. Distro updates reintroduce default configuration frequently.
8. A tested reboot: a hardened host that does not boot after a reboot is worse than an unhardened one. A mandatory reboot in the validation pipeline — mounts, lockdown, module signing, TPM/LUKS, modules_disabled and initramfs are only really verified at boot.

5. Security of the hardening process itself

• The baseline's supply chain is a supply chain: hardening roles are pinned by version/tag — never main —, the diff is reviewed on update and they are run from your own repo or an internal mirror. A role that runs as root across the whole fleet is the most profitable target you have. Verify the signature when the provider publishes it (ansible-lockdown releases are GPG-signed).
• An abandoned role = a risk, not a saving: before adopting any hardening content, verify the last release and its activity (§8). An unmaintained role applies an expired benchmark and gives a feeling of compliance.
• The scanner is not harmless: oscap with --remediate modifies the system. Automatic remediation in production from the scan is forbidden; the scan measures, the code applies.
• Secrets: GRUB passwords, boot hashes, LUKS keys, become_pass and agent credentials go in Vault/sops, never in the repo nor in role variables in the clear. A GRUB password hash in a public repo is an exposed credential.
• Compliance reports are sensitive data: an OpenSCAP ARF/HTML is a map of the host's exact weaknesses. Restricted access, not in an open bucket nor in the pipeline's public artifact.
• A record of who hardens: baseline changes are run from CI with their own identity and are audited. Nobody applies a hardening role from their laptop with their personal account.
• Hardening does not replace patching: 2026 has left explicit examples of kernel flaws that void the baseline's guarantees (local root escalations and MAC bypasses operating below the policy layer). When the finding is in the kernel, the only reliable mitigation is to patch and reboot — coordinate it with vulnerability-management-standards.

6. Operability and cost

• Every control has a cost; the one you do not measure is paid for in production. Measure with the real workload before pinning: CPU mitigations (verified order of magnitude: ~1-10% depending on the case, §3.4), auditd (I/O and CPU proportional to the number of rules), AIDE (scan I/O: off-peak), MemoryDenyWriteExecute (incompatible with JIT), noexec (breaks installers), lockdown=confidentiality (breaks profiling and debugging).
• Compliance telemetry: export the score per host as a metric and alert on a downward trend and on hosts not scanned in N days. A host that has stopped reporting is a control failure, not a gap in the dashboard.
• Diagnosis under a hardened system: document in the runbook how to debug with dmesg_restrict, ptrace_scope and ProtectProc=invisible active — otherwise, the first serious incident will end wit

…(truncated)