bitenforcer

bitenforcer liest eine deklarative Härtungsrichtlinie und beantwortet eine Frage vollständig:

„Wenn ich das auf diese Maschine anwenden würde: was genau würde sich ändern — und was könnte es mit meinem Zugang machen?“

Release	0.1.0-ga, Commit 4c6ce93, gebaut mit go1.25.12
Plattformen	Nur Linux amd64/arm64 — macOS und Windows werden nicht veröffentlicht, und warum
Lieferkette	Reproduzierbarer Build, CycloneDX-SBOM, cosign-Signatur, SBOM-Attestierung, signierte SHA256SUMS
Gestalt	Einmalig ausgeführtes Kommandozeilenwerkzeug. Kein Daemon, keine Telemetrie, kein Heartbeat

v1 ändert keine Hosts

bitenforcer v1 liefert validate und apply --dry-run aus. Er plant jede Änderung, validiert den Inhalt, den er schreiben würde, führt seine Lockout-Guards aus — und hält dann an. Er schreibt nicht auf den Host, und kein Flag bringt ihn dazu.

Das ist eine bewusste Entscheidung über den Funktionsumfang, kein Fehler, kein Ausfall und keine Einstellung, die Ihnen fehlt. Warum ist zehn Minuten Ihrer Zeit wert, bevor Sie einen Rollout planen.

Die Guards selbst und die vollständige Darlegung, warum die Durchsetzung außerhalb des Funktionsumfangs liegt, stehen auf Guards, und warum v1 nicht durchsetzt.

Was er tut

Richten Sie ihn auf eine YAML-Richtlinie:

bitenforcer validate --config policy.yaml            # is the policy well-formed?
bitenforcer apply    --config policy.yaml --dry-run  # what would it do to THIS host?

Der Pre-Flight benennt jede Datei, die er schreiben würde, und die Bytes, die er schreiben würde, jede systemd-Unit, die er aktivieren, deaktivieren, maskieren oder in die er ein Härtungs-Fragment ablegen würde, jede Firewall-Regel, jeden sysctl, jedes Konto und jede Berechtigung — in der Reihenfolge, in der sie angewendet würden.

Wo ein echter Validator existiert, wird der Kandidateninhalt durch ihn hindurchgeschickt:

Artefakt	Validator
sshd_config	sshd -t -f <candidate>
sudoers	visudo -c
nftables-Regelwerk	nft -c -f <candidate>
iptables-Regelwerk	iptables-restore --test

So wird „diese Richtlinie erzeugt eine sshd_config, die sshd ablehnen wird“ erkannt, bevor jemand dafür geradestehen muss — und nicht um 03:00 Uhr, wenn der Daemon nicht mehr startet.

Daneben melden die Lockout-Guards, was Ihre Richtlinie mit Ihrem eigenen Zugang machen würde, gemessen an der Sitzung, in der Sie tatsächlich arbeiten.

Was er nicht tun wird, ist raten. Ein Modul, dessen Voraussetzungen fehlen, meldet einen Fehler, statt etwas anzunehmen. Eine Sitzung, die nicht gemessen werden kann, wird als ungemessen gemeldet, niemals als „niemand ist gefährdet“. Ein Validator, der nicht laufen kann, sagt pro Datei NOT VALIDATED samt Grund, statt zu suggerieren, der Inhalt sei geprüft worden.

Echte Pre-Flight-Ausgabe

Dies ist ein tatsächlicher Lauf des ausgelieferten 0.1.0-ga-Binaries gegen die Vorlage standard, auf einem gewöhnlichen Ubuntu-Host, als Nicht-Root-Benutzer. Lediglich die IP-Adresse des Operators wurde durch eine Dokumentationsadresse ersetzt und ein sehr langer nft-Fehlerblock gekürzt.

$ bitenforcer generate --template standard --output-file policy.yaml
Example configuration written to policy.yaml

$ bitenforcer validate --config policy.yaml
Configuration 'standard-hardening' is valid.
  Environment : staging
  Compliance  : [CIS-L1]
  A valid policy is not a safe one: run `bitenforcer apply --dry-run` to see what it
  would change and which guards fire.
  (FR) Politique valide. Une politique valide n'est pas pour autant sûre : utilisez
  `apply --dry-run`.

$ bitenforcer apply --config policy.yaml --dry-run

=== PRE-FLIGHT: every change this run would make ===
  operator "ubuntu" is on an SSH session whose peer socket was NOT measured
  (SSH_CONNECTION/SSH_CLIENT in this process's environment (an inherited, settable
  environment variable -- a hint, NOT a measured socket)); any address in the
  environment is a hint, not evidence

  NOT EXAMINED on this host (the rest of the pre-flight below is unaffected):
    selinux: SELinux prerequisites check failed: SELinux tools not found
             (getenforce not in PATH)
    These modules were SKIPPED, not found compliant — this run says nothing
    about whether the host matches that part of the policy.
    (FR) Modules NON EXAMINÉS sur cet hôte : ignorés, et non déclarés conformes.
   1. [command] users /etc/passwd
      chmod 0644 /etc/passwd
   2. [command] users /etc/passwd
      chown root:root /etc/passwd
   3. [command] users /etc/shadow
      chmod 0640 /etc/shadow
   4. [command] users /etc/shadow
      chown root:root /etc/shadow
   5. [command] users /etc/group
      chmod 0644 /etc/group
   6. [command] users /etc/group
      chown root:root /etc/group
   7. [command] users /etc/gshadow
      chmod 0640 /etc/gshadow
   8. [command] users /etc/gshadow
      chown root:root /etc/gshadow
   9. [file-write] ssh /etc/ssh/sshd_config
      1194 bytes, mode 0600, validated with sshd -t -f <candidate>; NOT VALIDATED in
      this dry run (the validator could not be run in this context: sshd -t needs root
      to read the host keys (sshd: no hostkeys available -- exiting.)) — re-run the
      dry run as root to validate
  10. [file-write] firewall /etc/nftables.conf
      566 bytes, mode 0600, validated with nft -c -f <candidate>; NOT VALIDATED in
      this dry run (nft -c needs root […]) — re-run the dry run as root to validate
  11. [file-write] kernel /etc/sysctl.d/99-bitenforcer.conf
      672 bytes, mode 0644, validated with sysctl key syntax check
  12. [command] kernel /etc/sysctl.d/99-bitenforcer.conf
      sysctl -p /etc/sysctl.d/99-bitenforcer.conf

=== PRE-FLIGHT ADVISORIES (the guards; they did NOT block this run) ===
  These are the lockout guards. They are advisory: they report the shapes they
  recognise, and seven independent reviewers each found one they did not — which is
  why this release does not apply anything. Treat a finding as a reason to change the
  policy, never as the full list of ways it could strand you. Re-run with
  --guards=blocking to have findings exit non-zero, e.g. to gate a policy in CI.
  1. [kernel-remote-access-loss] this run would set net.ipv4.conf.all.rp_filter=1,
     which drops any packet whose reply route does not leave by the interface it
     arrived on
    evidence: bitenforcer measures the interface carrying your session (eth0)
              but not this host's routing table, so it cannot show that the route back
              to 198.51.100.24 leaves by that same interface. On a host with two
              uplinks, a VPN, or asymmetric routing, strict reverse-path filtering
              drops your session and every future connection from that address
    remedy:   run `ip route get 198.51.100.24` and confirm it leaves by eth0;
              if it does, say so for this one parameter, and keep a second session
              open while you apply
    override: re-run with --acknowledge kernel-remote-access-loss (this guard only)
  2. [kernel-remote-access-loss] this run would set net.ipv4.ip_forward=0, and
     bitenforcer cannot establish whether this host routes the network your session
     arrives through
    …

DRY RUN: nothing above was applied and this host was not changed.
This is the only mode bitenforcer v1 runs in; enforcement is not part of this release.
(FR) SIMULATION : rien n'a été appliqué et cet hôte n'a pas été modifié.

Drei Dinge in dieser Ausgabe sind das ganze Produkt:

1. NOT EXAMINED ist eine Antwort, keine Auslassung. Auf einem Standard-Ubuntu fehlt das SELinux-Werkzeug, deshalb wird das selinux-Modul als übersprungen und ausdrücklich nicht als konform befunden gemeldet, und der Rest des Pre-Flight läuft weiter. Ein Lauf, der zu einer Kontrolle nichts sagt, ist etwas völlig anderes als ein Lauf, der sagt, die Kontrolle sei in Ordnung.
2. NOT VALIDATED nennt den Grund, pro Datei. sshd -t braucht Root, um die Host-Schlüssel zu lesen; deshalb sagt Ihnen das Werkzeug als normaler Benutzer, dass der Inhalt nicht geprüft wurde und was Sie dagegen tun können — statt stillschweigend zu suggerieren, er sei es gewesen.
3. Die Guard-Feststellung trägt Belege, eine Abhilfe und ein Override pro Guard. Sie sagt nicht „riskant“. Sie sagt, welcher Parameter, was gemessen wurde, was nicht gemessen werden konnte, und den genauen Befehl, den Sie ausführen sollten, um die Frage zu klären.

Was Ihnen das heute bringt

Es ist leicht, „wendet keine Änderungen an“ als „tut nichts“ zu lesen. Hier ist, was ein Werkzeug, das ausschließlich Pre-Flight leistet, Ihnen tatsächlich einbringt:

• Ein Artefakt für das Änderungsfenster. Hängen Sie die Pre-Flight-Ausgabe an den Änderungsantrag. Jede Datei, jede Unit, jede Regel und jeder sysctl, in Reihenfolge, mit den Bytes.
• Ein CI-Gate. --guards=blocking lässt die Pipeline scheitern, wenn eine Baseline den Zugang kappen würde, bevor sie einen Host erreicht.
• Kaputte Richtlinieninhalte früh erkennen. sshd -t und nft -c laufen gegen den Kandidaten-Inhalt, sodass eine Richtlinie, die eine nicht parsbare Konfiguration erzeugt, schon im Review auffällt.
• Drift, auf die Sie sicher reagieren können. Führen Sie den Probelauf auf einer Flotte aus und lesen Sie, was jeder Host als das meldet, was er bräuchte — ohne jede Möglichkeit, versehentlich etwas zu ändern.
• Eine ehrliche Abdeckungskarte. NOT EXAMINED sagt Ihnen, wo das Werkzeug nichts zu sagen hat, damit Sie Schweigen nicht mit Konformität verwechseln.

Policy as Code

bitenforcer generate --template standard --output-file policy.yaml

Vorlagen: minimal, standard, strict. Es sind feste Ausgangspunkte zum Bearbeiten — sie lesen nicht den Host und leiten keine Sicherheitslage von der Maschine ab, auf der Sie sie ausgeführt haben. Erzeugte Richtlinien sind rundlauffähig: Geben Sie die Ausgabe wieder in validate, und sie besteht.

validate geht weiter als eine Schemaprüfung: Eine Richtlinie, die einen Schlüssel setzt, den nichts implementiert, wird beim Laden namentlich zurückgewiesen, mit einer Aussage darüber, was nicht passiert. Eine Einstellung, die geparst wird, aber wirkungslos ist, ist genau der Defekt, den diese Produkte einen Monat lang aus sich selbst entfernt haben.

Eine gültige Richtlinie ist keine sichere Richtlinie

validate liest die Richtliniendatei und sonst nichts — es sieht sich diesen Host nicht an. Führen Sie bitenforcer apply --config <file> --dry-run aus, um herauszufinden, was sich hier ändern würde.

Plattformen

0.1.0-ga veröffentlicht zwei signierte Binaries, und die Lücke ist beabsichtigt:

Plattform	Veröffentlicht	Warum
Linux amd64	Ja
Linux arm64	Ja
macOS amd64/arm64	Nein	Zurückgehalten — siehe unten
Windows amd64	Nein	Zurückgehalten — siehe unten

bitenforcer ist Linux-only, weil sein gesamter Gegenstand Linux ist. Jedes Modul, das er plant, betrifft einen Linux-Mechanismus: iptables/nftables-Regelwerke, sysctl-Schlüssel unter /proc/sys, systemd-Units, SELinux und AppArmor sowie /etc/passwd, /etc/shadow, /etc/gshadow und sudoers mit ihren POSIX-Modi und -Eigentümern. Dasselbe gilt für die Validatoren, durch die er den Kandidateninhalt laufen lässt — sshd -t, visudo -c, nft -c, iptables-restore --test.

Ein macOS- oder Windows-Build würde kompilieren. Genau das ist das Problem: Er würde starten, eine Richtlinie annehmen und einen Pre-Flight erzeugen, in dem jedes Modul NOT EXAMINED ist — ein Bericht, der wie ein erfolgreicher Lauf aussieht und nichts über den Host aussagt. Da dieses Werkzeug dazu da ist, Ihnen vor einer Änderung zu sagen, was sie bewirken würde, ist ein Binary, dessen ehrliche Ausgabe „ich habe zu dieser Maschine nichts zu sagen“ lautet, schlechter als gar kein Binary. Es wird nicht veröffentlicht, damit niemand es für Abdeckung hält.

Wenn Sie die Härtungs-Posture eines macOS-Hosts brauchen, ist das der posture-Collector von bitcollector, der auf macOS ausgeliefert wird und je Kontrolle meldet, ob sie beobachtet, nicht beobachtet oder vom Agenten dort nicht unterstützt wurde.

Nächste Schritte

• Guards, und warum v1 nicht durchsetzt — die achtzehn Lockout-Guards, das CI-Gate und warum der Durchsetzungspfad bewusst nicht in diesem Release ist.
• Ihre Downloads verifizieren — tun Sie das vor dem ersten Lauf.
• bitcollector — die berichtende Hälfte des Paares, und woher die kontinuierlichen Nachweise zur Sicherheitslage kommen.
• Compliance-Frameworks — wie die Kontrollen zugeordnet werden.